[Buildroot] make troubles

[Buildroot] make troubles

[Robert Carter]

Hi list,

I'm just getting started with buildroot and i'm having some trouble
building. I'm using the daily buildroot snapshot tarball from
02-Aug-2006 00:15. I am using the default .config file created by 

make menuconfig

with only default options (I don't make changes to any options).

The build runs for a while but fails in the end with an error. If I run
make once more I get the output below. 

Rob

http://organicdesign.co.nz/Special:Recentchanges
-------------------------------------------------------

root at turing:~/buildroot# make

Checking build system dependencies:
sed works:                          Ok
GNU make version '3.81beta4':       Ok
gcc version '4.0.3':                Ok
which installed:                    Ok
bison installed:                    Ok
flex installed:                     Ok
gettext installed:                  Ok
Build system dependencies:          Ok

make -j1
CC=/home/rob/buildroot/build_i686/staging_dir/bin/i686-linux-uclibc-gcc
CROSS_COMPILE="/home/rob/buildroot/build_i686/staging_dir/bin/i686-linux-uclibc-" CROSS="/home/rob/buildroot/build_i686/staging_dir/bin/i686-linux-uclibc-" PREFIX="/home/rob/buildroot/build_i686/root" \
                EXTRA_CFLAGS="-Os -pipe "
-C /home/rob/buildroot/build_i686/busybox
make[1]: Entering directory `/home/rob/buildroot/build_i686/busybox'
  CC modutils/lsmod.o
/home/rob/buildroot/build_i686/busybox/modutils/lsmod.c: In function
`lsmod_main':
/home/rob/buildroot/build_i686/busybox/modutils/lsmod.c:96: warning:
dereferencing type-punned pointer will break strict-aliasing rules
/home/rob/buildroot/build_i686/busybox/modutils/lsmod.c:114: warning:
dereferencing type-punned pointer will break strict-aliasing rules
make[2]: *** [/home/rob/buildroot/build_i686/busybox/modutils/lsmod.o]
Error 1
make[1]: *** [_all] Error 2
make[1]: Leaving directory `/home/rob/buildroot/build_i686/busybox'
make: *** [/home/rob/buildroot/build_i686/busybox/busybox] Error 2

root at turing:~/buildroot# make
Checking build system dependencies:
sed works:                          Ok
GNU make version '3.81beta4':       Ok
gcc version '4.0.3':                Ok
which installed:                    Ok
bison installed:                    Ok
flex installed:                     Ok
gettext installed:                  Ok
Build system dependencies:          Ok

make -j1
CC=/home/rob/buildroot/build_i686/staging_dir/bin/i686-linux-uclibc-gcc
CROSS_COMPILE="/home/rob/buildroot/build_i686/staging_dir/bin/i686-linux-uclibc-" CROSS="/home/rob/buildroot/build_i686/staging_dir/bin/i686-linux-uclibc-" PREFIX="/home/rob/buildroot/build_i686/root" \
                EXTRA_CFLAGS="-Os -pipe "
-C /home/rob/buildroot/build_i686/busybox
make[1]: Entering directory `/home/rob/buildroot/build_i686/busybox'
  CC modutils/lsmod.o
/home/rob/buildroot/build_i686/busybox/modutils/lsmod.c: In function
`lsmod_main':
/home/rob/buildroot/build_i686/busybox/modutils/lsmod.c:96: warning:
dereferencing type-punned pointer will break strict-aliasing rules
/home/rob/buildroot/build_i686/busybox/modutils/lsmod.c:114: warning:
dereferencing type-punned pointer will break strict-aliasing rules
make[2]: *** [/home/rob/buildroot/build_i686/busybox/modutils/lsmod.o]
Error 1
make[1]: *** [_all] Error 2
make[1]: Leaving directory `/home/rob/buildroot/build_i686/busybox'
make: *** [/home/rob/buildroot/build_i686/busybox/busybox] Error 2

[Buildroot] make troubles

[Rob Landley]

On Thursday 03 August 2006 2:00 am, Robert Carter wrote:
> make[1]: Entering directory `/home/rob/buildroot/build_i686/busybox'
>   CC modutils/lsmod.o
> /home/rob/buildroot/build_i686/busybox/modutils/lsmod.c: In function
> `lsmod_main':
> /home/rob/buildroot/build_i686/busybox/modutils/lsmod.c:96: warning:
> dereferencing type-punned pointer will break strict-aliasing rules
> /home/rob/buildroot/build_i686/busybox/modutils/lsmod.c:114: warning:
> dereferencing type-punned pointer will break strict-aliasing rules
> make[2]: *** [/home/rob/buildroot/build_i686/busybox/modutils/lsmod.o]
> Error 1

Odd.  I'm not seeing that.  Still, I just committed svn 15773 in an attempt to 
make this go away.  Try now?

If that doesn't work, you could always use the stable version of BusyBox 
(1.2.1).  We have actual releases which are recent enough to matter. :)

Rob
-- 
Never bet against the cheap plastic solution.

[Buildroot] make troubles

[Robert Carter]

I did a svn update to 15773 and ran the build once again with the  
same result.

The good news is that when

BR_PACKAGE_BUSYBOX_SNAPSHOT

is not set and busybox-1.2.1 is used the build succeeds. So perhaps  
the problem is with some of the recent 'testing' busybox commits.

Your help much appreciated.
Rob

On 4/08/2006, at 8:39 AM, Rob Landley wrote:

> On Thursday 03 August 2006 2:00 am, Robert Carter wrote:
>> make[1]: Entering directory `/home/rob/buildroot/build_i686/busybox'
>>   CC modutils/lsmod.o
>> /home/rob/buildroot/build_i686/busybox/modutils/lsmod.c: In function
>> `lsmod_main':
>> /home/rob/buildroot/build_i686/busybox/modutils/lsmod.c:96: warning:
>> dereferencing type-punned pointer will break strict-aliasing rules
>> /home/rob/buildroot/build_i686/busybox/modutils/lsmod.c:114: warning:
>> dereferencing type-punned pointer will break strict-aliasing rules
>> make[2]: *** [/home/rob/buildroot/build_i686/busybox/modutils/ 
>> lsmod.o]
>> Error 1
>
> Odd.  I'm not seeing that.  Still, I just committed svn 15773 in an  
> attempt to
> make this go away.  Try now?
>
> If that doesn't work, you could always use the stable version of  
> BusyBox
> (1.2.1).  We have actual releases which are recent enough to  
> matter. :)
>
> Rob
> -- 
> Never bet against the cheap plastic solution.

[Buildroot] make troubles

[Rob Landley]

On Thursday 03 August 2006 8:36 pm, Robert Carter wrote:
> I did a svn update to 15773 and ran the build once again with the  
> same result.
> 
> The good news is that when
> 
> BR_PACKAGE_BUSYBOX_SNAPSHOT
> 
> is not set and busybox-1.2.1 is used the build succeeds. So perhaps  
> the problem is with some of the recent 'testing' busybox commits.

I switched on -Werror to break on warnings during the devel cycle, but 
different versions of gcc produce different warnings and most of them are 
entirely spurious.  (The gcc developers have this nasty habit of thinking 
that their compiler is more important that the software it's compiling.  If 
the Linux kernel guys felt that way, we'd need to rebuild the whole of 
userspace with every dot-release...)

I switched them off for 4.1 because lots of the warnings that produces are 
confirmed non-problems that would cost us size to work around.  (If the code 
does "if(a) x=1; else x=thingy();" then x is _not_ uninitialized after that.  
Trust me on this one!)  As far as warnings go it's a deeply broken compiler 
and -Werror just isn't feasible.

With 4.0 it's mostly warning about things which are at least conceivably real 
under certain lighting conditions.

Rob
-- 
Never bet against the cheap plastic solution.

[Buildroot] make troubles

[Robert Carter]

I'm beginning to understand what a strange creature gcc is. I found  
this page during my research. Perhaps it might help in visualising  
the various combinations of compilers and libraries on different  
architectures.

http://kegel.com/crosstool/crosstool-0.42/buildlogs/

Rob

On 5/08/2006, at 6:18 AM, Rob Landley wrote:

> On Thursday 03 August 2006 8:36 pm, Robert Carter wrote:
>> I did a svn update to 15773 and ran the build once again with the
>> same result.
>>
>> The good news is that when
>>
>> BR_PACKAGE_BUSYBOX_SNAPSHOT
>>
>> is not set and busybox-1.2.1 is used the build succeeds. So perhaps
>> the problem is with some of the recent 'testing' busybox commits.
>
> I switched on -Werror to break on warnings during the devel cycle, but
> different versions of gcc produce different warnings and most of  
> them are
> entirely spurious.  (The gcc developers have this nasty habit of  
> thinking
> that their compiler is more important that the software it's  
> compiling.  If
> the Linux kernel guys felt that way, we'd need to rebuild the whole of
> userspace with every dot-release...)
>
> I switched them off for 4.1 because lots of the warnings that  
> produces are
> confirmed non-problems that would cost us size to work around.  (If  
> the code
> does "if(a) x=1; else x=thingy();" then x is _not_ uninitialized  
> after that.
> Trust me on this one!)  As far as warnings go it's a deeply broken  
> compiler
> and -Werror just isn't feasible.
>
> With 4.0 it's mostly warning about things which are at least  
> conceivably real
> under certain lighting conditions.
>
> Rob
> -- 
> Never bet against the cheap plastic solution.