[Buildroot] package/linux/Makefile.in does not include 'openswan' patches

[Buildroot] package/linux/Makefile.in does not include 'openswan' patches

[Ulf Samuelsson]

The Kernel Headers buildscript applies the openswan patches 
on top of the kernel headers, but the target/linux/Makefile.in does not.

Isn't this a bug?

Best Regards
Ulf Samuelsson

[Buildroot] package/linux/Makefile.in does not include 'openswan' patches

[Bernhard Fischer]

On Mon, Jul 23, 2007 at 03:11:26PM +0200, Ulf Samuelsson wrote:
>The Kernel Headers buildscript applies the openswan patches 
>on top of the kernel headers, but the target/linux/Makefile.in does not.

The headers (which used the very same sourcedir, dunno if it still does
with your toolchain/linux* stuff) have to be patched. To achieve this,
we patch the source before installing the headers.
>
>Isn't this a bug?

I don't understand? You can't apply patches twice, if you mean to
suggests this (you most likely don't, i assume).

[Buildroot] package/linux/Makefile.in does not include 'openswan' patches

[Ulf Samuelsson]

> On Mon, Jul 23, 2007 at 03:11:26PM +0200, Ulf Samuelsson wrote:
>>The Kernel Headers buildscript applies the openswan patches 
>>on top of the kernel headers, but the target/linux/Makefile.in does not.
> 
> The headers (which used the very same sourcedir, dunno if it still does
> with your toolchain/linux* stuff) have to be patched. To achieve this,
> we patch the source before installing the headers.
>>

I didn't add BSP patch support for Linux, Stephen did,
but already before the BSP patch, the Linux was built
in a separate dir if the the kernel version was not the same
as the kernel-headers.

>>Isn't this a bug?
> 
> I don't understand? You can't apply patches twice, if you mean to
> suggests this (you most likely don't, i assume).
>

The kernel headers are installed in $(STAGING_DIR) and 
with the BSP patch you can have a separate kernel source directory for
each special configuration of the kernel, so the current kernel is 
installed in $(PROJECT_BUILD_DIR)/linux-$(LINUX26_VERSION)

The kernel in $(PROJECT_BUILD_DIR) does not get patched with openswan,
and even when a separate kernel source was built in $(BUILD_DIR), 
it did not get patched unless the kernel version was the same as the kernel header version.

I assume that this means we have to update target/linux/Makefile.in...

I also noted that the openswan patches are rather large.
Maybe we should have them downloadable from some location
instead of part of the buildroot trunk.
Each patchset for a kernel version is close to 2 MB.

Best Regards
Ulf Samuelsson

[Buildroot] package/linux/Makefile.in does not include 'openswan' patches

[Bernhard Fischer]

On Mon, Jul 23, 2007 at 03:29:36PM +0200, Bernhard Fischer wrote:
>On Mon, Jul 23, 2007 at 03:11:26PM +0200, Ulf Samuelsson wrote:
>>The Kernel Headers buildscript applies the openswan patches 
>>on top of the kernel headers, but the target/linux/Makefile.in does not.
>
>The headers (which used the very same sourcedir, dunno if it still does
>with your toolchain/linux* stuff) have to be patched. To achieve this,
>we patch the source before installing the headers.
>>
>>Isn't this a bug?
>
>I don't understand? You can't apply patches twice, if you mean to
>suggests this (you most likely don't, i assume).

ok, you broke building a linux kernel.

excerpt:
make[1]: Leaving directory
`/scratch/obj.i686/buildroot.mine/toolchain_build_i386/module-init-tools-3.2.2'
touch -c
/scratch/obj.i686/buildroot.mine/toolchain_build_i386/module-init-tools-3.2.2/depmod
/usr/bin/install -D
/scratch/obj.i686/buildroot.mine/toolchain_build_i386/module-init-tools-3.2.2/depmod
/scratch/obj.i686/buildroot.mine/build_i386/staging_dir/bin/i386-linux-depmod26
make: *** No rule to make target
`/scratch/obj.i686/buildroot.mine/project_build_i386//linux-2.6.21.5/.patched',
needed by
`/scratch/obj.i686/buildroot.mine/project_build_i386//linux-2.6.21.5/.configured'.
Stop.


This is due to this PROJECT thing. Please revert immediately or fix ASAP.

While i understand that it's possible that one thing or another can
break in the course of changes, i ask you to be more careful.

regards,

[Buildroot] package/linux/Makefile.in does not include 'openswan' patches

[Bernhard Fischer]

On Mon, Jul 23, 2007 at 04:22:07PM +0200, Bernhard Fischer wrote:
>On Mon, Jul 23, 2007 at 03:29:36PM +0200, Bernhard Fischer wrote:

>make: *** No rule to make target
>`/scratch/obj.i686/buildroot.mine/project_build_i386//linux-2.6.21.5/.patched',
>needed by
>`/scratch/obj.i686/buildroot.mine/project_build_i386//linux-2.6.21.5/.configured'.
>Stop.
>
>
>This is due to this PROJECT thing. Please revert immediately or fix ASAP.

By now i have reverted these incorrect hunks in svn.
>
>While i understand that it's possible that one thing or another can
>break in the course of changes, i ask you to be more careful.

I suggest you
ifneq ($(PROJECT_BUILD_DIR),)
fixup_after_ulf=O=$(PROJECT_BUILD_DIR)
endif
LINUX26_MAKE_FLAGS+=$(fixup_after_ulf)

but you were about to do the same anyway, weren't you..

[Buildroot] package/linux/Makefile.in does not include 'openswan' patches

[Ulf Samuelsson]

> On Mon, Jul 23, 2007 at 03:29:36PM +0200, Bernhard Fischer wrote:
>>On Mon, Jul 23, 2007 at 03:11:26PM +0200, Ulf Samuelsson wrote:
>>>The Kernel Headers buildscript applies the openswan patches 
>>>on top of the kernel headers, but the target/linux/Makefile.in does not.
>>
>>The headers (which used the very same sourcedir, dunno if it still does
>>with your toolchain/linux* stuff) have to be patched. To achieve this,
>>we patch the source before installing the headers.
>>>
>>>Isn't this a bug?
>>
>>I don't understand? You can't apply patches twice, if you mean to
>>suggests this (you most likely don't, i assume).
> 
> ok, you broke building a linux kernel.
> 

No, Stephen did...
He patched the linux makefile with the BSP patch.
Please give the credit where it is due.

> excerpt:
> make[1]: Leaving directory
> `/scratch/obj.i686/buildroot.mine/toolchain_build_i386/module-init-tools-3.2.2'
> touch -c
> /scratch/obj.i686/buildroot.mine/toolchain_build_i386/module-init-tools-3.2.2/depmod
> /usr/bin/install -D
> /scratch/obj.i686/buildroot.mine/toolchain_build_i386/module-init-tools-3.2.2/depmod
> /scratch/obj.i686/buildroot.mine/build_i386/staging_dir/bin/i386-linux-depmod26
> make: *** No rule to make target
> `/scratch/obj.i686/buildroot.mine/project_build_i386//linux-2.6.21.5/.patched',
> needed by
> `/scratch/obj.i686/buildroot.mine/project_build_i386//linux-2.6.21.5/.configured'.
> Stop.
> 
> 
> This is due to this PROJECT thing. Please revert immediately or fix ASAP.
> 
> While i understand that it's possible that one thing or another can
> break in the course of changes, i ask you to be more careful.
> 

Please be more careful in who you are addressing your  comments. 

Furthermore, it would be more constructive to patch the module-init-tools.

I generated the linux-experimental directory, to be able to do more tests and I got flak for that.

> regards,


Best Regards
Ulf Samuelsson

[Buildroot] package/linux/Makefile.in does not include 'openswan' patches

[Ulf Samuelsson]

----- Original Message ----- 
From: "Bernhard Fischer" <rep.dot.nop@gmail.com>
To: "Ulf Samuelsson" <ulf@atmel.com>
Cc: "buildroot" <buildroot@uclibc.org>
Sent: Monday, July 23, 2007 4:43 PM
Subject: Re: [Buildroot] package/linux/Makefile.in does not include 'openswan' patches


> On Mon, Jul 23, 2007 at 04:22:07PM +0200, Bernhard Fischer wrote:
>>On Mon, Jul 23, 2007 at 03:29:36PM +0200, Bernhard Fischer wrote:
> 
>>make: *** No rule to make target
>>`/scratch/obj.i686/buildroot.mine/project_build_i386//linux-2.6.21.5/.patched',
>>needed by
>>`/scratch/obj.i686/buildroot.mine/project_build_i386//linux-2.6.21.5/.configured'.
>>Stop.
>>
>>
>>This is due to this PROJECT thing. Please revert immediately or fix ASAP.
> 
> By now i have reverted these incorrect hunks in svn.
>>

You did not fix this, since you assume that the kernel headers and the kernel is the same.
If they are not, the bug is still there, so it is NOT because of the BSP stuff,
and you fixed the symptom, not the cause.
Try setting LINUX26_VERSION to 2.6.22.1 and build with openswan,
and you see what I mean.

>>While i understand that it's possible that one thing or another can
>>break in the course of changes, i ask you to be more careful.
> 
> I suggest you
> ifneq ($(PROJECT_BUILD_DIR),)
> fixup_after_ulf=O=$(PROJECT_BUILD_DIR)
> endif
> LINUX26_MAKE_FLAGS+=$(fixup_after_ulf)
> 
> but you were about to do the same anyway, weren't you..
>

No, I want to have two ways of building linux, 
until the BSP stuff is fully tested, and then merge into one.
Not fill the single linux makefile with a lot of kludges
which has no long term validity.

Best Regards
Ulf Samuelsson

[Buildroot] "multiple target patterns" error while building under cygwin

[Crane, Matthew]

Hi, 


I'm trying to build on cygwin, busybox is failing with the error:


applets/.applets.o.cmd:410: *** multiple target patterns.  Stop.

Has anybody come across this?  I'm wondering if it's related to the case
insensitivity of cygwin.  Any help much apreciated, 

Matt


More complete error log, starts just as the build process has run
through building busybox once, and starts again, which I think is
normal??


  AR      util-linux/lib.a
  LINK    busybox_unstripped
cp busybox_unstripped busybox
make[1]: Leaving directory
`/usr/local/src/hd2/buildroot-20070718/project_build_arm_nofpu/uclibc/bu
sybox-1.6.1'
/usr/bin/make -j1 CC=/usr/local/arm2007-uc/bin/arm-uclinuxeabi-gcc
CROSS_COMPILE="/usr/local/arm2007-uc/bin/arm-uclinuxeabi-
" \
                CROSS="/usr/local/arm2007-uc/bin/arm-uclinuxeabi-"
PREFIX="/usr/local/src/hd2/buildroot-20070718/project_bui
ld_arm_nofpu/uclibc/root" \
                ARCH=arm \
                EXTRA_CFLAGS="-Os -pipe
-I/usr/local/src/hd2/buildroot-20070718/build_arm_nofpu/staging_dir/incl
ude -I/usr/
local/src/hd2/buildroot-20070718/build_arm_nofpu/staging_dir/usr/include
-I/usr/local/arm2007-uc/arm-uclinuxeabi/include" -C
 
/usr/local/src/hd2/buildroot-20070718/project_build_arm_nofpu/uclibc/bus
ybox-1.6.1 install
make[1]: Entering directory
`/usr/local/src/hd2/buildroot-20070718/project_build_arm_nofpu/uclibc/bu
sybox-1.6.1'
  HOSTCC  scripts/basic/split-include
scripts/basic/.split-include.d: done.
  HOSTCC  scripts/basic/docproc
scripts/basic/.docproc.d: done.
  SPLIT   include/autoconf.h -> include/config/*
  GEN     include/bbconfigopts.h
applets/.applets.o.cmd:410: *** multiple target patterns.  Stop.
make[1]: *** [applets] Error 2
make[1]: Leaving directory
`/usr/local/src/hd2/buildroot-20070718/project_build_arm_nofpu/uclibc/bu
sybox-1.6.1'
make: ***
[/usr/local/src/hd2/buildroot-20070718/project_build_arm_nofpu/uclibc/ro
ot/bin/busybox] Error 2

[Buildroot] package/linux/Makefile.in does not include 'openswan' patches

[Bernhard Fischer]

On Mon, Jul 23, 2007 at 05:19:36PM +0200, Ulf Samuelsson wrote:
>> On Mon, Jul 23, 2007 at 03:29:36PM +0200, Bernhard Fischer wrote:
>>>On Mon, Jul 23, 2007 at 03:11:26PM +0200, Ulf Samuelsson wrote:
>>>>The Kernel Headers buildscript applies the openswan patches 
>>>>on top of the kernel headers, but the target/linux/Makefile.in does not.
>>>
>>>The headers (which used the very same sourcedir, dunno if it still does
>>>with your toolchain/linux* stuff) have to be patched. To achieve this,
>>>we patch the source before installing the headers.
>>>>
>>>>Isn't this a bug?
>>>
>>>I don't understand? You can't apply patches twice, if you mean to
>>>suggests this (you most likely don't, i assume).
>> 
>> ok, you broke building a linux kernel.
>> 
>
>No, Stephen did...
>He patched the linux makefile with the BSP patch.
>Please give the credit where it is due.

Please accept my apologies. This BSP stuff should not have been applied
in it's current incarnation :(

[Buildroot] package/linux/Makefile.in does not include 'openswan' patches

[Bernhard Fischer]

On Mon, Jul 23, 2007 at 05:25:33PM +0200, Ulf Samuelsson wrote:
>----- Original Message ----- 
>From: "Bernhard Fischer" <rep.dot.nop@gmail.com>
>To: "Ulf Samuelsson" <ulf@atmel.com>
>Cc: "buildroot" <buildroot@uclibc.org>
>Sent: Monday, July 23, 2007 4:43 PM
>Subject: Re: [Buildroot] package/linux/Makefile.in does not include 'openswan' patches
>
>
>> On Mon, Jul 23, 2007 at 04:22:07PM +0200, Bernhard Fischer wrote:
>>>On Mon, Jul 23, 2007 at 03:29:36PM +0200, Bernhard Fischer wrote:
>> 
>>>make: *** No rule to make target
>>>`/scratch/obj.i686/buildroot.mine/project_build_i386//linux-2.6.21.5/.patched',
>>>needed by
>>>`/scratch/obj.i686/buildroot.mine/project_build_i386//linux-2.6.21.5/.configured'.
>>>Stop.
>>>
>>>
>>>This is due to this PROJECT thing. Please revert immediately or fix ASAP.
>> 
>> By now i have reverted these incorrect hunks in svn.
>>>
>
>You did not fix this, since you assume that the kernel headers and the kernel is the same.

I did not mean to imply that it is a fix. I only use the kernel headers
from the kernel i'm using since i see absolutely no benefit (or any
reason) to use something else, personally.

>If they are not, the bug is still there, so it is NOT because of the BSP stuff,
>and you fixed the symptom, not the cause.

I'm not mixing headers and source from different versions but use just
one version for both. This serves my purposes very well.
I don't use nor actively support mixed headers, fwiw. If somebody
expresses a need for such a setup and provides a clean, tested patch
that does not break the common case to use both headers and kernel from
the same source, then fine with me.

>Try setting LINUX26_VERSION to 2.6.22.1 and build with openswan,
>and you see what I mean.
>
>>>While i understand that it's possible that one thing or another can
>>>break in the course of changes, i ask you to be more careful.
>> 
>> I suggest you
>> ifneq ($(PROJECT_BUILD_DIR),)
>> fixup_after_ulf=O=$(PROJECT_BUILD_DIR)
>> endif
>> LINUX26_MAKE_FLAGS+=$(fixup_after_ulf)
>> 
>> but you were about to do the same anyway, weren't you..
>>
>
>No, I want to have two ways of building linux, 
>until the BSP stuff is fully tested, and then merge into one.
>Not fill the single linux makefile with a lot of kludges
>which has no long term validity.

The target/linux/Makefile.in is currently 115 lines (without comments
and whitespace). It provides quite generic rules to unpack, configure
and build a kernel.
What kludges are you referring to specifically?

Using a single source-tree and installing (e.g. via O=) into the
obj-tree is a nice thing, not mandatory though.

[Buildroot] package/linux/Makefile.in does not include 'openswan' patches

[Ulf Samuelsson]

m?n 2007-07-23 klockan 18:41 +0200 skrev Bernhard Fischer:
> On Mon, Jul 23, 2007 at 05:19:36PM +0200, Ulf Samuelsson wrote:
> >> On Mon, Jul 23, 2007 at 03:29:36PM +0200, Bernhard Fischer wrote:
> >>>On Mon, Jul 23, 2007 at 03:11:26PM +0200, Ulf Samuelsson wrote:
> >>>>The Kernel Headers buildscript applies the openswan patches 
> >>>>on top of the kernel headers, but the target/linux/Makefile.in does not.
> >>>
> >>>The headers (which used the very same sourcedir, dunno if it still does
> >>>with your toolchain/linux* stuff) have to be patched. To achieve this,
> >>>we patch the source before installing the headers.
> >>>>
> >>>>Isn't this a bug?
> >>>
> >>>I don't understand? You can't apply patches twice, if you mean to
> >>>suggests this (you most likely don't, i assume).
> >> 
> >> ok, you broke building a linux kernel.
> >> 
> >
> >No, Stephen did...
> >He patched the linux makefile with the BSP patch.
> >Please give the credit where it is due.
> 
> Please accept my apologies. This BSP stuff should not have been applied
> in it's current incarnation :(

We need eventually to move to using the BSP for the Linux,
but it needs to be tested thoroughly.
I will move pre-your-revert target/linux/Makefile.in
to target/linux-experimental/Makefile.in so 
that we can continue testing.
 
Again, the package/linux.mk was broken well before that
and only worked properly if the kernel and the kernel-headers
was the same, and applying the BSP patch on top of the linux.mk
was therefore a good thing, because it ironed out an existing
nasty bug, even if it caused hassle for You and others
using the same kernel + headers.

Best Regards,
Ulf Samuelsson

[Buildroot] "multiple target patterns" error while building under cygwin

[Rex Ashbaugh]

It could be a 'make' version issue
or a 'sh' shell version issue,
or script  syntax issue,
or a dos path issue.

What text is at line 410 of the file 'applets.o.cmd' ?



On 7/23/07, Crane, Matthew <mcrane03@harris.com> wrote:
>
> Hi,
>
>
> I'm trying to build on cygwin, busybox is failing with the error:
>
>
> applets/.applets.o.cmd:410: *** multiple target patterns.  Stop.
>
> Has anybody come across this?  I'm wondering if it's related to the case
> insensitivity of cygwin.  Any help much apreciated,
>
> Matt
>
>
> More complete error log, starts just as the build process has run
> through building busybox once, and starts again, which I think is
> normal??
>
>
>   AR      util-linux/lib.a
>   LINK    busybox_unstripped
> cp busybox_unstripped busybox
> make[1]: Leaving directory
> `/usr/local/src/hd2/buildroot-20070718/project_build_arm_nofpu/uclibc/bu
> sybox-1.6.1'
> /usr/bin/make -j1 CC=/usr/local/arm2007-uc/bin/arm-uclinuxeabi-gcc
> CROSS_COMPILE="/usr/local/arm2007-uc/bin/arm-uclinuxeabi-
> " \
>                 CROSS="/usr/local/arm2007-uc/bin/arm-uclinuxeabi-"
> PREFIX="/usr/local/src/hd2/buildroot-20070718/project_bui
> ld_arm_nofpu/uclibc/root" \
>                 ARCH=arm \
>                 EXTRA_CFLAGS="-Os -pipe
> -I/usr/local/src/hd2/buildroot-20070718/build_arm_nofpu/staging_dir/incl
> ude -I/usr/
> local/src/hd2/buildroot-20070718/build_arm_nofpu/staging_dir/usr/include
> -I/usr/local/arm2007-uc/arm-uclinuxeabi/include" -C
>
> /usr/local/src/hd2/buildroot-20070718/project_build_arm_nofpu/uclibc/bus
> ybox-1.6.1 install
> make[1]: Entering directory
> `/usr/local/src/hd2/buildroot-20070718/project_build_arm_nofpu/uclibc/bu
> sybox-1.6.1'
>   HOSTCC  scripts/basic/split-include
> scripts/basic/.split-include.d: done.
>   HOSTCC  scripts/basic/docproc
> scripts/basic/.docproc.d: done.
>   SPLIT   include/autoconf.h -> include/config/*
>   GEN     include/bbconfigopts.h
> applets/.applets.o.cmd:410: *** multiple target patterns.  Stop.
> make[1]: *** [applets] Error 2
> make[1]: Leaving directory
> `/usr/local/src/hd2/buildroot-20070718/project_build_arm_nofpu/uclibc/bu
> sybox-1.6.1'
> make: ***
> [/usr/local/src/hd2/buildroot-20070718/project_build_arm_nofpu/uclibc/ro
> ot/bin/busybox] Error 2
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/buildroot/attachments/20070725/9ce5e45f/attachment.htm 

[Buildroot] "multiple target patterns" error while building under cygwin

[Crane, Matthew]

Hi, 
 
Thanks for your response.  I think my build error is the result of the
dos2unix + unix2dos patch.  My cygwin system was installed with Unix
text mode, and I've tried to explicitly set the locale, but fixdep
always seems to output the Dos text. 

I instead used the dos2unix/unix2dos patch to fix the fixdep output,
which I think ending up causing the error below.  Not sure how though,
or how to fix it.  Thanks,

Matt

 
.applets.o.cmd looks like this:
 
cmd_applets/applets.o := <snip>
 
deps_applets/applets.o := \
  applets/applets.c \
    $(wildcard include/config/static.h) \
    $(wildcard include/config/show/usage.h) \
<snip>
 
line 410: applets/applets.o: $(deps_applets/applets.o)
 
$(deps_applets/applets.o):
<eof>
 
I had already patched the make process so that it runs fixdep through
unix2dos, dos2unix similar to this patch I found online:
 
define rule_cc_o_c
     $(call echo-cmd,checksrc) $(cmd_checksrc)              \
     $(call echo-cmd,cc_o_c) $(cmd_cc_o_c);                  \
+    dos2unix $(depfile);                                              \
     $(cmd_modversions)                          \
-    scripts/basic/fixdep $(depfile) $@ '$(call make-cmd,cc_o_c)' >    \

+ scripts/basic/fixdep $(depfile) $@ '$(call make-cmd,cc_o_c)' |
unix2dos > \ 
                                                   $(dot-target).tmp;  \
     rm -f $(depfile);                          \
     mv -f $(dot-target).tmp $(dot-target).cmd

It proceeded to build, but failed with the above error.   Maybe related,
not sure.  I'm looking forward to the day when cygwin support is
completely transparent in buildroot, soon I'm sure.



-----Original Message-----
From: Bernhard Fischer [mailto:rep.dot.nop at gmail.com] 
Sent: Friday, July 27, 2007 12:27 PM
To: Crane, Matthew
Cc: busybox at busybox.net
Subject: "multiple target patterns" error while building under cygwin

Please paste lines 409-411 (take care not to word-wrap it).
Just to be sure, untar the busybox into a separate dir, then 'make
defconfig && make'. I expect this to happen there too..

thanks,

On Mon, Jul 23, 2007 at 12:33:58PM -0400, Crane, Matthew wrote:
>Hi, 
>
>
>I'm trying to build on cygwin, busybox is failing with the error:
>
>
>applets/.applets.o.cmd:410: *** multiple target patterns.  Stop.
>
>Has anybody come across this?  I'm wondering if it's related to the
case
>insensitivity of cygwin.  Any help much apreciated, 
>
>Matt
>
>
>More complete error log, starts just as the build process has run
>through building busybox once, and starts again, which I think is
>normal??
>
>
>  AR      util-linux/lib.a
>  LINK    busybox_unstripped
>cp busybox_unstripped busybox
>make[1]: Leaving directory
>`/usr/local/src/hd2/buildroot-20070718/project_build_arm_nofpu/uclibc/b
u
>sybox-1.6.1'
>/usr/bin/make -j1 CC=/usr/local/arm2007-uc/bin/arm-uclinuxeabi-gcc
>CROSS_COMPILE="/usr/local/arm2007-uc/bin/arm-uclinuxeabi-
>" \
>                CROSS="/usr/local/arm2007-uc/bin/arm-uclinuxeabi-"
>PREFIX="/usr/local/src/hd2/buildroot-20070718/project_bui
>ld_arm_nofpu/uclibc/root" \
>                ARCH=arm \
>                EXTRA_CFLAGS="-Os -pipe
>-I/usr/local/src/hd2/buildroot-20070718/build_arm_nofpu/staging_dir/inc
l
>ude -I/usr/
>local/src/hd2/buildroot-20070718/build_arm_nofpu/staging_dir/usr/includ
e
>-I/usr/local/arm2007-uc/arm-uclinuxeabi/include" -C
> 
>/usr/local/src/hd2/buildroot-20070718/project_build_arm_nofpu/uclibc/bu
s
>ybox-1.6.1 install
>make[1]: Entering directory
>`/usr/local/src/hd2/buildroot-20070718/project_build_arm_nofpu/uclibc/b
u
>sybox-1.6.1'
>  HOSTCC  scripts/basic/split-include
>scripts/basic/.split-include.d: done.
>  HOSTCC  scripts/basic/docproc
>scripts/basic/.docproc.d: done.
>  SPLIT   include/autoconf.h -> include/config/*
>  GEN     include/bbconfigopts.h
>applets/.applets.o.cmd:410: *** multiple target patterns.  Stop.

[Buildroot] "multiple target patterns" error while building under cygwin

[Bernhard Fischer]

On Fri, Jul 27, 2007 at 01:04:00PM -0400, Crane, Matthew wrote:
>Hi, 
> 
>Thanks for your response.  I think my build error is the result of the
>dos2unix + unix2dos patch.  My cygwin system was installed with Unix
>text mode, and I've tried to explicitly set the locale, but fixdep
>always seems to output the Dos text. 
>
>I instead used the dos2unix/unix2dos patch to fix the fixdep output,
>which I think ending up causing the error below.  Not sure how though,
>or how to fix it.  Thanks,
>
>Matt
>
> 
>.applets.o.cmd looks like this:
> 
>cmd_applets/applets.o := <snip>
> 
>deps_applets/applets.o := \
>  applets/applets.c \
>    $(wildcard include/config/static.h) \
>    $(wildcard include/config/show/usage.h) \
><snip>
> 
>line 410: applets/applets.o: $(deps_applets/applets.o)
> 
>$(deps_applets/applets.o):
><eof>
> 
>I had already patched the make process so that it runs fixdep through
>unix2dos, dos2unix similar to this patch I found online:
> 
>define rule_cc_o_c
>     $(call echo-cmd,checksrc) $(cmd_checksrc)              \
>     $(call echo-cmd,cc_o_c) $(cmd_cc_o_c);                  \
>+    dos2unix $(depfile);                                              \
>     $(cmd_modversions)                          \
>-    scripts/basic/fixdep $(depfile) $@ '$(call make-cmd,cc_o_c)' >    \
>
>+ scripts/basic/fixdep $(depfile) $@ '$(call make-cmd,cc_o_c)' |
>unix2dos > \ 
>                                                   $(dot-target).tmp;  \
>     rm -f $(depfile);                          \
>     mv -f $(dot-target).tmp $(dot-target).cmd
>
>It proceeded to build, but failed with the above error.   Maybe related,
>not sure.  I'm looking forward to the day when cygwin support is
>completely transparent in buildroot, soon I'm sure.

This doesn't really sounds like a buildroot issue to me but rather a
busybox issue, fwiw.

Perhaps somebody else is aware of what's going on with busybox on
cygwin.