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 _______________________________________________ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community