[Buildroot] Build failure with 2010.08-rc1

[Buildroot] Build failure with 2010.08-rc1

[Will Newton]

Hi,

buildroot 2010.08-rc1 is failing to build for me part way through the
initial gcc build.

/home/ldap/wnewton/src/metag-buildroot2/output/toolchain/gcc-4.2.4-initial/./gcc/xgcc
-B/home/ldap/wnewton/src/metag-buildroot2/output/toolchain/gcc-4.2.4-initial/./gcc/
-B/home/ldap/wnewton/src/metag-buildroot2/output/build/staging_dir/usr/metag-unknown-linux-uclibc/bin/
-B/home/ldap/wnewton/src/metag-buildroot2/output/build/staging_dir/usr/metag-unknown-linux-uclibc/lib/
-isystem /home/ldap/wnewton/src/metag-buildroot2/output/build/staging_dir/usr/metag-unknown-linux-uclibc/include
-isystem /home/ldap/wnewton/src/metag-buildroot2/output/build/staging_dir/usr/metag-unknown-linux-uclibc/sys-include
-O2  -g -Os -DIN_GCC -DCROSS_COMPILE   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include  -fomit-frame-pointer -fPIC -g0 -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I.
-I/home/ldap/wnewton/src/metag-buildroot2/output/toolchain/gcc-4.2.4/gcc
-I/home/ldap/wnewton/src/metag-buildroot2/output/toolchain/gcc-4.2.4/gcc/.
-I/home/ldap/wnewton/src/metag-buildroot2/output/toolchain/gcc-4.2.4/gcc/../include
-I/home/ldap/wnewton/src/metag-buildroot2/output/toolchain/gcc-4.2.4/gcc/../libcpp/include
-I/home/ldap/wnewton/src/metag-buildroot2/output/toolchain/gmp/include
-I/home/ldap/wnewton/src/metag-buildroot2/output/toolchain/mpfr/include
-I/home/ldap/wnewton/src/metag-buildroot2/output/toolchain/gcc-4.2.4/gcc/../libdecnumber
-I../libdecnumber  -fexceptions -c
/home/ldap/wnewton/src/metag-buildroot2/output/toolchain/gcc-4.2.4/gcc/unwind-dw2.c
-o libgcc/./unwind-dw2.o
In file included from ./gthr-default.h:1,
                 from
/home/ldap/wnewton/src/metag-buildroot2/output/toolchain/gcc-4.2.4/gcc/gthr.h:114,
                 from
/home/ldap/wnewton/src/metag-buildroot2/output/toolchain/gcc-4.2.4/gcc/unwind-dw2.c:42:
/home/ldap/wnewton/src/metag-buildroot2/output/toolchain/gcc-4.2.4/gcc/gthr-posix.h:43:21:
error: pthread.h: No such file or directory
/home/ldap/wnewton/src/metag-buildroot2/output/toolchain/gcc-4.2.4/gcc/gthr-posix.h:44:20:
error: unistd.h: No such file or directory

Which appears to be caused by trying to build gcc without headers. I
assume the configure --with-newlib is intended to build against the
newlib headers? How is this intended to work as by default gcc does
not ship with newlib?

[Buildroot] Build failure with 2010.08-rc1

[Will Newton]

On Tue, Aug 10, 2010 at 1:22 PM, Will Newton <will.newton@gmail.com> wrote:
> Hi,
>
> buildroot 2010.08-rc1 is failing to build for me part way through the
> initial gcc build.
>
> /home/ldap/wnewton/src/metag-buildroot2/output/toolchain/gcc-4.2.4-initial/./gcc/xgcc
> -B/home/ldap/wnewton/src/metag-buildroot2/output/toolchain/gcc-4.2.4-initial/./gcc/
> -B/home/ldap/wnewton/src/metag-buildroot2/output/build/staging_dir/usr/metag-unknown-linux-uclibc/bin/
> -B/home/ldap/wnewton/src/metag-buildroot2/output/build/staging_dir/usr/metag-unknown-linux-uclibc/lib/
> -isystem /home/ldap/wnewton/src/metag-buildroot2/output/build/staging_dir/usr/metag-unknown-linux-uclibc/include
> -isystem /home/ldap/wnewton/src/metag-buildroot2/output/build/staging_dir/usr/metag-unknown-linux-uclibc/sys-include
> -O2 ?-g -Os -DIN_GCC -DCROSS_COMPILE ? -W -Wall -Wwrite-strings
> -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
> -isystem ./include ?-fomit-frame-pointer -fPIC -g0 -DHAVE_GTHR_DEFAULT
> -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I.
> -I/home/ldap/wnewton/src/metag-buildroot2/output/toolchain/gcc-4.2.4/gcc
> -I/home/ldap/wnewton/src/metag-buildroot2/output/toolchain/gcc-4.2.4/gcc/.
> -I/home/ldap/wnewton/src/metag-buildroot2/output/toolchain/gcc-4.2.4/gcc/../include
> -I/home/ldap/wnewton/src/metag-buildroot2/output/toolchain/gcc-4.2.4/gcc/../libcpp/include
> -I/home/ldap/wnewton/src/metag-buildroot2/output/toolchain/gmp/include
> -I/home/ldap/wnewton/src/metag-buildroot2/output/toolchain/mpfr/include
> -I/home/ldap/wnewton/src/metag-buildroot2/output/toolchain/gcc-4.2.4/gcc/../libdecnumber
> -I../libdecnumber ?-fexceptions -c
> /home/ldap/wnewton/src/metag-buildroot2/output/toolchain/gcc-4.2.4/gcc/unwind-dw2.c
> -o libgcc/./unwind-dw2.o
> In file included from ./gthr-default.h:1,
> ? ? ? ? ? ? ? ? from
> /home/ldap/wnewton/src/metag-buildroot2/output/toolchain/gcc-4.2.4/gcc/gthr.h:114,
> ? ? ? ? ? ? ? ? from
> /home/ldap/wnewton/src/metag-buildroot2/output/toolchain/gcc-4.2.4/gcc/unwind-dw2.c:42:
> /home/ldap/wnewton/src/metag-buildroot2/output/toolchain/gcc-4.2.4/gcc/gthr-posix.h:43:21:
> error: pthread.h: No such file or directory
> /home/ldap/wnewton/src/metag-buildroot2/output/toolchain/gcc-4.2.4/gcc/gthr-posix.h:44:20:
> error: unistd.h: No such file or directory
>
> Which appears to be caused by trying to build gcc without headers. I
> assume the configure --with-newlib is intended to build against the
> newlib headers? How is this intended to work as by default gcc does
> not ship with newlib?

This problem appears to only affect gcc 4.2.4.

[Buildroot] Build failure with 2010.08-rc1

[Thomas Petazzoni]

On Tue, 10 Aug 2010 14:23:35 +0100
Will Newton <will.newton@gmail.com> wrote:

> This problem appears to only affect gcc 4.2.4.

Interesting. I'm 100% sure that 2 weeks ago, gcc 4.2.2 for AVR32 was
building correctly. And with today's Git, it doesn't build, failing
with the exact same error message you're having.

I'm currently retrying the build with the Git as it was two weeks ago
and will start bisecting. I'm kind of suspecting the changes made to
the gcc build procedure to support NPTL in uClibc.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Build failure with 2010.08-rc1

[Will Newton]

On Tue, Aug 10, 2010 at 5:23 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> On Tue, 10 Aug 2010 14:23:35 +0100
> Will Newton <will.newton@gmail.com> wrote:
>
>> This problem appears to only affect gcc 4.2.4.
>
> Interesting. I'm 100% sure that 2 weeks ago, gcc 4.2.2 for AVR32 was
> building correctly. And with today's Git, it doesn't build, failing
> with the exact same error message you're having.
>
> I'm currently retrying the build with the Git as it was two weeks ago
> and will start bisecting. I'm kind of suspecting the changes made to
> the gcc build procedure to support NPTL in uClibc.

Hi Thomas,

Yes, it is that patch that has caused the failure. Unfortunately there
is no simple fix I have found just yet. gcc prior to 4.3 always
attempts to build libgcc which will fail with the new build process.

[Buildroot] Build failure with 2010.08-rc1

[Will Newton]

On Tue, Aug 10, 2010 at 5:23 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> On Tue, 10 Aug 2010 14:23:35 +0100
> Will Newton <will.newton@gmail.com> wrote:
>
>> This problem appears to only affect gcc 4.2.4.
>
> Interesting. I'm 100% sure that 2 weeks ago, gcc 4.2.2 for AVR32 was
> building correctly. And with today's Git, it doesn't build, failing
> with the exact same error message you're having.
>
> I'm currently retrying the build with the Git as it was two weeks ago
> and will start bisecting. I'm kind of suspecting the changes made to
> the gcc build procedure to support NPTL in uClibc.

Hi Thomas,

The attached hacky patch allows it to build a bit further, although it
now blows up with an error later in the build. I think it's unrelated
however:

/home/ldap/wnewton/src/git/buildroot/output/toolchain/gcc-4.2.4-final/./gcc/xgcc
-shared-libgcc -B/home/ldap/wnewton/src/git/buildroot/output/toolchain/gcc-4.2.4-final/./gcc
-nostdinc++ -L/home/ldap/wnewton/src/git/buildroot/output/toolchain/gcc-4.2.4-final/i686-unknown-linux-uclibc/libstdc++-v3/src
-L/home/ldap/wnewton/src/git/buildroot/output/toolchain/gcc-4.2.4-final/i686-unknown-linux-uclibc/libstdc++-v3/src/.libs
-B/home/ldap/wnewton/src/git/buildroot/output/staging/usr/i686-unknown-linux-uclibc/bin/
-B/home/ldap/wnewton/src/git/buildroot/output/staging/usr/i686-unknown-linux-uclibc/lib/
-isystem /home/ldap/wnewton/src/git/buildroot/output/staging/usr/i686-unknown-linux-uclibc/include
-isystem /home/ldap/wnewton/src/git/buildroot/output/staging/usr/i686-unknown-linux-uclibc/sys-include
-I/home/ldap/wnewton/src/git/buildroot/output/toolchain/gcc-4.2.4-final/i686-unknown-linux-uclibc/libstdc++-v3/include/i686-unknown-linux-uclibc
-I/home/ldap/wnewton/src/git/buildroot/output/toolchain/gcc-4.2.4-final/i686-unknown-linux-uclibc/libstdc++-v3/include
-I/home/ldap/wnewton/src/git/buildroot/output/toolchain/gcc-4.2.4/libstdc++-v3/libsupc++
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-g -Os -c ctype_members.cc  -fPIC -DPIC -o .libs/ctype_members.o
ctype_members.cc: In constructor
'std::ctype_byname<_CharT>::ctype_byname(const char*, size_t) [with
_CharT = char]':
ctype_members.cc:59: error: invalid use of incomplete type 'struct
__uclibc_locale_struct'
/home/ldap/wnewton/src/git/buildroot/output/staging/usr/i686-unknown-linux-uclibc/sys-include/bits/uClibc_locale.h:85:
error: forward declaration of 'struct __uclibc_locale_struct'
ctype_members.cc:60: error: invalid use of incomplete type 'struct
__uclibc_locale_struct'
/home/ldap/wnewton/src/git/buildroot/output/staging/usr/i686-unknown-linux-uclibc/sys-include/bits/uClibc_locale.h:85:
error: forward declaration of 'struct __uclibc_locale_struct'
ctype_members.cc:61: error: invalid use of incomplete type 'struct
__uclibc_locale_struct'
/home/ldap/wnewton/src/git/buildroot/output/staging/usr/i686-unknown-linux-uclibc/sys-include/bits/uClibc_locale.h:85:
error: forward declaration of 'struct __uclibc_locale_struct'
make[5]: *** [ctype_members.lo] Error 1
make[5]: *** Waiting for unfinished jobs....
make[5]: Leaving directory
`/home/ldap/wnewton/src/git/buildroot/output/toolchain/gcc-4.2.4-final/i686-unknown-linux-uclibc/libstdc++-v3/src'

Time to turn off uClibc locales I think...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc_4_2_4.patch
Type: text/x-patch
Size: 2501 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20100811/d1602301/attachment.bin>

[Buildroot] Build failure with 2010.08-rc1

[Thomas Petazzoni]

On Wed, 11 Aug 2010 14:43:26 +0100
Will Newton <will.newton@gmail.com> wrote:

> -g -Os -c ctype_members.cc  -fPIC -DPIC -o .libs/ctype_members.o
> ctype_members.cc: In constructor
> 'std::ctype_byname<_CharT>::ctype_byname(const char*, size_t) [with
> _CharT = char]':
> ctype_members.cc:59: error: invalid use of incomplete type 'struct
> __uclibc_locale_struct'
> /home/ldap/wnewton/src/git/buildroot/output/staging/usr/i686-unknown-linux-uclibc/sys-include/bits/uClibc_locale.h:85:
> error: forward declaration of 'struct __uclibc_locale_struct'
> ctype_members.cc:60: error: invalid use of incomplete type 'struct
> __uclibc_locale_struct'
> /home/ldap/wnewton/src/git/buildroot/output/staging/usr/i686-unknown-linux-uclibc/sys-include/bits/uClibc_locale.h:85:
> error: forward declaration of 'struct __uclibc_locale_struct'
> ctype_members.cc:61: error: invalid use of incomplete type 'struct
> __uclibc_locale_struct'
> /home/ldap/wnewton/src/git/buildroot/output/staging/usr/i686-unknown-linux-uclibc/sys-include/bits/uClibc_locale.h:85:
> error: forward declaration of 'struct __uclibc_locale_struct'
> make[5]: *** [ctype_members.lo] Error 1
> make[5]: *** Waiting for unfinished jobs....
> make[5]: Leaving directory
> `/home/ldap/wnewton/src/git/buildroot/output/toolchain/gcc-4.2.4-final/i686-unknown-linux-uclibc/libstdc++-v3/src'
> 
> Time to turn off uClibc locales I think...

Ah, ah. I thought this problem was only affecting the AVR32
architecture, so we added 60f945e47a15e10f0e777f69b05492b6f7ba918d to
the tree to prevent uClibc 0.9.31 + C++ + locale from being choosen on
AVR32. But it seems that 0.9.31 + C++ + locale fails to build on any
architecture with gcc 4.2.

I've discussed the issue a few weeks ago with Berhnard on IRC, but I
didn't quite get what the solution was.

Concerning the original problem, I've started discussing with Khem on
IRC, but he didn't manage to reproduce it for some reason. One possible
solution is to somehow revert to the two-stage gcc build procedure for
gcc 4.2 and use the three-stage gcc build procedure only for gcc 4.3+.
But I'd prefer to have Khem opinion on this beforehand.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Build failure with 2010.08-rc1

[Will Newton]

On Wed, Aug 11, 2010 at 2:55 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> On Wed, 11 Aug 2010 14:43:26 +0100
> Will Newton <will.newton@gmail.com> wrote:
>
>> -g -Os -c ctype_members.cc ?-fPIC -DPIC -o .libs/ctype_members.o
>> ctype_members.cc: In constructor
>> 'std::ctype_byname<_CharT>::ctype_byname(const char*, size_t) [with
>> _CharT = char]':
>> ctype_members.cc:59: error: invalid use of incomplete type 'struct
>> __uclibc_locale_struct'
>> /home/ldap/wnewton/src/git/buildroot/output/staging/usr/i686-unknown-linux-uclibc/sys-include/bits/uClibc_locale.h:85:
>> error: forward declaration of 'struct __uclibc_locale_struct'
>> ctype_members.cc:60: error: invalid use of incomplete type 'struct
>> __uclibc_locale_struct'
>> /home/ldap/wnewton/src/git/buildroot/output/staging/usr/i686-unknown-linux-uclibc/sys-include/bits/uClibc_locale.h:85:
>> error: forward declaration of 'struct __uclibc_locale_struct'
>> ctype_members.cc:61: error: invalid use of incomplete type 'struct
>> __uclibc_locale_struct'
>> /home/ldap/wnewton/src/git/buildroot/output/staging/usr/i686-unknown-linux-uclibc/sys-include/bits/uClibc_locale.h:85:
>> error: forward declaration of 'struct __uclibc_locale_struct'
>> make[5]: *** [ctype_members.lo] Error 1
>> make[5]: *** Waiting for unfinished jobs....
>> make[5]: Leaving directory
>> `/home/ldap/wnewton/src/git/buildroot/output/toolchain/gcc-4.2.4-final/i686-unknown-linux-uclibc/libstdc++-v3/src'
>>
>> Time to turn off uClibc locales I think...
>
> Ah, ah. I thought this problem was only affecting the AVR32
> architecture, so we added 60f945e47a15e10f0e777f69b05492b6f7ba918d to
> the tree to prevent uClibc 0.9.31 + C++ + locale from being choosen on
> AVR32. But it seems that 0.9.31 + C++ + locale fails to build on any
> architecture with gcc 4.2.
>
> I've discussed the issue a few weeks ago with Berhnard on IRC, but I
> didn't quite get what the solution was.
>
> Concerning the original problem, I've started discussing with Khem on
> IRC, but he didn't manage to reproduce it for some reason. One possible
> solution is to somehow revert to the two-stage gcc build procedure for
> gcc 4.2 and use the three-stage gcc build procedure only for gcc 4.3+.
> But I'd prefer to have Khem opinion on this beforehand.

It should be fairly simple to reproduce with a clean cloned tree:

# make i686_defconfig
# make menuconfig (switch compiler to 4.2.4)
# make

I disabled locales and the build almost completes successfully with my
hack in place, but unfortunately gdbserver and busybox fail to build
claiming there is no usleep defined:

libbb/lib.a(inet_common.o): In function `INET_rresolve':
inet_common.c:(.text.INET_rresolve+0xa8): warning: gethostbyaddr is
obsolescent, use getaddrinfo() instead.
util-linux/lib.a(mount.o): In function `nfsmount':
mount.c:(.text.nfsmount+0xdb): warning: gethostbyname is obsolescent,
use getnameinfo() instead.
miscutils/lib.a(beep.o): In function `beep_main':
beep.c:(.text.beep_main+0xf1): undefined reference to `usleep'
beep.c:(.text.beep_main+0x10d): undefined reference to `usleep'
miscutils/lib.a(watchdog.o): In function `watchdog_main':
watchdog.c:(.text.watchdog_main+0xfb): undefined reference to `usleep'
networking/lib.a(ifupdown.o): In function `dhcp_down':
ifupdown.c:(.text.dhcp_down+0x1d): undefined reference to `usleep'
networking/lib.a(traceroute.o): In function `common_traceroute_main':
traceroute.c:(.text.common_traceroute_main+0x5c3): undefined reference
to `usleep'
procps/lib.a(top.o):top.c:(.text.top_main+0x216): more undefined
references to `usleep' follow
collect2: ld returned 1 exit status
make[1]: *** [busybox_unstripped] Error 1
make[1]: Leaving directory
`/home/ldap/wnewton/src/git/buildroot/output/build/busybox-1.17.1'

I'm not sure why that is happening yet...

[Buildroot] Build failure with 2010.08-rc1

[Khem Raj]

On (11/08/10 16:19), Will Newton wrote:
> On Wed, Aug 11, 2010 at 2:55 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > On Wed, 11 Aug 2010 14:43:26 +0100
> > Will Newton <will.newton@gmail.com> wrote:

> 
> It should be fairly simple to reproduce with a clean cloned tree:
> 
> # make i686_defconfig
> # make menuconfig (switch compiler to 4.2.4)
> # make
> 

OK I could reproduce it with above. Here is patch for it
http://lists.busybox.net/pipermail/buildroot/2010-August/036783.html

test it and apply it if appropriate.

-Khem

[Buildroot] Build failure with 2010.08-rc1

[Will Newton]

On Wed, Aug 11, 2010 at 4:19 PM, Will Newton <will.newton@gmail.com> wrote:
> On Wed, Aug 11, 2010 at 2:55 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> On Wed, 11 Aug 2010 14:43:26 +0100
>> Will Newton <will.newton@gmail.com> wrote:
>>
>>> -g -Os -c ctype_members.cc ?-fPIC -DPIC -o .libs/ctype_members.o
>>> ctype_members.cc: In constructor
>>> 'std::ctype_byname<_CharT>::ctype_byname(const char*, size_t) [with
>>> _CharT = char]':
>>> ctype_members.cc:59: error: invalid use of incomplete type 'struct
>>> __uclibc_locale_struct'
>>> /home/ldap/wnewton/src/git/buildroot/output/staging/usr/i686-unknown-linux-uclibc/sys-include/bits/uClibc_locale.h:85:
>>> error: forward declaration of 'struct __uclibc_locale_struct'
>>> ctype_members.cc:60: error: invalid use of incomplete type 'struct
>>> __uclibc_locale_struct'
>>> /home/ldap/wnewton/src/git/buildroot/output/staging/usr/i686-unknown-linux-uclibc/sys-include/bits/uClibc_locale.h:85:
>>> error: forward declaration of 'struct __uclibc_locale_struct'
>>> ctype_members.cc:61: error: invalid use of incomplete type 'struct
>>> __uclibc_locale_struct'
>>> /home/ldap/wnewton/src/git/buildroot/output/staging/usr/i686-unknown-linux-uclibc/sys-include/bits/uClibc_locale.h:85:
>>> error: forward declaration of 'struct __uclibc_locale_struct'
>>> make[5]: *** [ctype_members.lo] Error 1
>>> make[5]: *** Waiting for unfinished jobs....
>>> make[5]: Leaving directory
>>> `/home/ldap/wnewton/src/git/buildroot/output/toolchain/gcc-4.2.4-final/i686-unknown-linux-uclibc/libstdc++-v3/src'
>>>
>>> Time to turn off uClibc locales I think...
>>
>> Ah, ah. I thought this problem was only affecting the AVR32
>> architecture, so we added 60f945e47a15e10f0e777f69b05492b6f7ba918d to
>> the tree to prevent uClibc 0.9.31 + C++ + locale from being choosen on
>> AVR32. But it seems that 0.9.31 + C++ + locale fails to build on any
>> architecture with gcc 4.2.
>>
>> I've discussed the issue a few weeks ago with Berhnard on IRC, but I
>> didn't quite get what the solution was.
>>
>> Concerning the original problem, I've started discussing with Khem on
>> IRC, but he didn't manage to reproduce it for some reason. One possible
>> solution is to somehow revert to the two-stage gcc build procedure for
>> gcc 4.2 and use the three-stage gcc build procedure only for gcc 4.3+.
>> But I'd prefer to have Khem opinion on this beforehand.
>
> It should be fairly simple to reproduce with a clean cloned tree:
>
> # make i686_defconfig
> # make menuconfig (switch compiler to 4.2.4)
> # make
>
> I disabled locales and the build almost completes successfully with my
> hack in place, but unfortunately gdbserver and busybox fail to build
> claiming there is no usleep defined:
>
> libbb/lib.a(inet_common.o): In function `INET_rresolve':
> inet_common.c:(.text.INET_rresolve+0xa8): warning: gethostbyaddr is
> obsolescent, use getaddrinfo() instead.
> util-linux/lib.a(mount.o): In function `nfsmount':
> mount.c:(.text.nfsmount+0xdb): warning: gethostbyname is obsolescent,
> use getnameinfo() instead.
> miscutils/lib.a(beep.o): In function `beep_main':
> beep.c:(.text.beep_main+0xf1): undefined reference to `usleep'
> beep.c:(.text.beep_main+0x10d): undefined reference to `usleep'
> miscutils/lib.a(watchdog.o): In function `watchdog_main':
> watchdog.c:(.text.watchdog_main+0xfb): undefined reference to `usleep'
> networking/lib.a(ifupdown.o): In function `dhcp_down':
> ifupdown.c:(.text.dhcp_down+0x1d): undefined reference to `usleep'
> networking/lib.a(traceroute.o): In function `common_traceroute_main':
> traceroute.c:(.text.common_traceroute_main+0x5c3): undefined reference
> to `usleep'
> procps/lib.a(top.o):top.c:(.text.top_main+0x216): more undefined
> references to `usleep' follow
> collect2: ld returned 1 exit status
> make[1]: *** [busybox_unstripped] Error 1
> make[1]: Leaving directory
> `/home/ldap/wnewton/src/git/buildroot/output/build/busybox-1.17.1'
>
> I'm not sure why that is happening yet...

This failure is caused by the i686_defconfig building uClibc 0.9.31
with a 0.9.30 config. The attached patch updates the i686_defconfig.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-i686_defconfig-Use-0.9.31-config-with-uClibc-0.9.31.patch
Type: text/x-patch
Size: 30216 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20100812/8a8f8756/attachment-0001.bin>

[Buildroot] Build failure with 2010.08-rc1

[Will Newton]

On Wed, Aug 11, 2010 at 9:49 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On (11/08/10 16:19), Will Newton wrote:
>> On Wed, Aug 11, 2010 at 2:55 PM, Thomas Petazzoni
>> <thomas.petazzoni@free-electrons.com> wrote:
>> > On Wed, 11 Aug 2010 14:43:26 +0100
>> > Will Newton <will.newton@gmail.com> wrote:
>
>>
>> It should be fairly simple to reproduce with a clean cloned tree:
>>
>> # make i686_defconfig
>> # make menuconfig (switch compiler to 4.2.4)
>> # make
>>
>
> OK I could reproduce it with above. Here is patch for it
> http://lists.busybox.net/pipermail/buildroot/2010-August/036783.html
>
> test it and apply it if appropriate.
>
> -Khem

Hi Khem,

I also had to patch unwind-dw2-fde.c too to get the patch to work on
my architecture. I have attached the updated patch.

I imagine we'll need one of these patches for each 4.2.x compiler version...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1001-gcc-4.2.x-inhibit-libc.patch
Type: text/x-patch
Size: 1859 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20100812/1a81297d/attachment.bin>