Toolchain alpha release

Werner Almesberger werner at openmoko.org
Sun Jan 6 02:59:39 CET 2008


John Lee wrote:
> http://downloads.openmoko.org/toolchains/openmoko-x86_64-arm-linux-gnueabi-toolchain.tar.bz2

I found one little problem with setup-env: when I try to build u-boot
or the kernel with it, ld fails due to the LDFLAGS, which are defined
as follows:

export LDFLAGS="-L${OMTOOL_DIR}/arm/arm-angstrom-linux-gnueabi/lib -Wl,-rpath-link,${OMTOOL_DIR}/arm/arm-angstrom-linux-gnueabi/lib -Wl,-O1"

Now, both u-boot and kernel invoke "ld" directly and not through "cc"
or "gcc". Unfortunately, "ld" doesn't understand the option -Wl, so
it fails.

We couldn't just omit the -Wl, since "gcc" doesn't understand -rpath-link,
and we wouldn't want to unconditionally compile with -O1 anyway. But in
what scenario do we actually need to set these flags ? As far as I can
tell, just plain use of arm-angstrom-linux-gnueabi-gcc or
arm-angstrom-linux-gnueabi-ld gets all the search paths right.

If we do have to set LDFLAGS, I can think of the following ways to work
around breaking u-boot and kernel builds:

1) don't use setup-env but define only PATH (which is all kernel and
   u-boot really need anyway)

2) make LDFLAGS= ...

3) LDFLAGS= make ...

What I don't like about 2) and 3) is that they make an already too long
command even longer, and that this may let more environment variables
slip through and cause subtle breakage. 1) looks much safer.

Would you agree that, if we have to keep LDFLAGS in setup-env,  1) best
reflects proper use of the toolchain in these cases ? If not, how would
you propose to solve this problem ?

- Werner




More information about the community mailing list