[Buildroot] [autobuild.buildroot.net] Build results for 2013-09-28

Michael Rommel rommel at layer-7.net
Sun Sep 29 14:02:43 UTC 2013


Hi Yann,

On Sep 29, 2013, at 15:58 , Yann E. MORIN <yann.morin.1998 at free.fr> wrote:

> 
>    depends on !BR2_PREFER_STATIC_LIB
> 

Great info - thanks!

> /home/test/test/1/output/host/usr/bin/arm-none-linux-gnueabi-gcc
>    [-- SNIP -D flags --]
>    -D_LINUX -D HAS_IFHEAD -D AICCU_TYPE="\"linux\""  --static -lgnutls
>    -lpthread -lresolv -o aiccu main.o ../common/tun.o ../common/aiccu.o
>    ../common/hash_md5.o ../common/hash_sha1.o ../common/common.o
>    ../common/heartbeat.o ../common/tic.o ../common/ayiya.o
>    ../common/aiccu_test.o ../common/resolver.o ../common/aiccu_linux.o
> 
> From ld's man page:
>    The linker will search an archive only once, at the location where
>    it is specified on the command line. If the archive defines a symbol
>    which was undefined in some object which appeared before the archive
>    on the command line, the linker will include the appropriate file(s)
>    from the archive. However, an undefined symbol in an object appearing
>    later on the command line will not cause the linker to search the
>    archive again.
> 
> Although all the interesting -l flags are present, they are before any
> of the .o files, so the libs won;t be searched for unresolved symbols.
> 
> To confirm this, just have a look at how gcc calls the linker, by adding
>    -v -Wl,--verbose
> 
> to the commandline above, and run it manually.
> 
> If I'm correct (which is still to be proven! ;-) ), we'll just have to
> devise how to fix aiccu…

I'll try that and look into reordering the object files and see if this makes a change!

Thanks for the pointer!

  Michael.








More information about the buildroot mailing list