[Buildroot] Issue for the integration of Codesourcery external toolchains
Thomas Petazzoni
thomas.petazzoni at free-electrons.com
Tue Jan 12 10:52:28 UTC 2010
Hello,
Thanks for your input!
On Tue, 05 Jan 2010 00:23:35 +0100
Lionel Landwerlin <llandwerlin at gmail.com> wrote:
> To me, probably the best solution...
> But why would it require a custom spec file ? --sysroot doesn't change
> the headers and librairies' default path in that case ?
--sysroot changes it, but the toolchain continues to append /armv4t at
the end:
$ /usr/local/xtools/arm-2009q1/bin/arm-none-linux-gnueabi-gcc --sysroot=/foo/bar -print-sysroot
/foo/bar
$ /usr/local/xtools/arm-2009q1/bin/arm-none-linux-gnueabi-gcc -march=armv4t --sysroot=/foo/bar -print-sysroot
/foo/bar/armv4t
See ?
Which is why I was talking about hacking the specs file. But I'm still
not there.
With the original spec file:
$ /usr/local/xtools/arm-2009q1/bin/arm-none-linux-gnueabi-gcc -specs=spec.orig -march=armv4t -print-multi-directory
armv4t
With a modified spec file:
$ /usr/local/xtools/arm-2009q1/bin/arm-none-linux-gnueabi-gcc -specs=spec -march=armv4t -print-multi-directory
.
Which looks good. But then:
$ /usr/local/xtools/arm-2009q1/bin/arm-none-linux-gnueabi-gcc -specs=spec -march=armv4t --sysroot=/foo/bar -print-sysroot
/foo/bar/armv4t
Still not working. So even by hacking the spec file I'm not able to get
the proper behaviour.
So maybe our solution of using --sysroot is ugly and we should fall
back to the solution where the toolchain sysroot is kept in its
original location and we just use -L/-I to indicate where our staging
directory is (solution which has proved in the past to be fairly
difficult to stabilize).
I really don't know how we should move forward.
> > Thanks for reading such a long mail, and thanks in advance for your
> > ideas!
>
> I never worked with codesourcery's toolchains (as not working with ARM
> chips).
> Is the set of toolchain you're using available somewhere ?
Yes, you can go to http://www.codesourcery.com/sgpp_eval.html and
register for a free evaluation.
> <Not_so_related>
>
> By the way, we still have some problem with the current scripts
> setting up the staging/target directories. Maybe I'm the only one who
> noticed/has_a_strange_setup...
>
> Just like every other linker script :
>
> $(STAGING_DIR)/usr/lib/libpthread.so
> $(STAGING_DIR)/usr/lib/libc.so
>
> might be processed to replace the default path, usually /lib/libc.so,
> by $(STAGING_DIR)/lib/libc.so.
Isn't this the "rpath" problem ?
> We also need to copy thoses linker scripts to the target directory.
I'm not sure which linker scripts you're talking about.
> Otherwise you generate some kind of fucked up binaries when installing
> librairies in target using libtool. In particular with the pthread_*
> symbols, because some of them are defined in libc.so as weak symbols.
> So you end up having librairies calling libc's weak symbols which
> volontary crash because they might be replaced by the pthread's ones
> when pthread.so is loaded.
I'm sorry, but I didn't understand what the problem is, under which
conditions it appears, and what the fix for it is (even if it's a quick
and hacky fix).
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
More information about the buildroot
mailing list