Toolchain alpha release

John Lee john_lee at
Mon Jan 7 06:53:08 CET 2008

On Sat, Jan 05, 2008 at 10:59:39PM -0300, Werner Almesberger wrote:
> 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 ?

Yes, I met this one before and I solved it by 1).  This environment
setting is dumped and modified from OE but the way it uses LDFLAGS is
strange.  However, if this got fixed, something other then kernel or
uboot might break, so I just leave it as it is.

I think if one wants to use toolchain this kind of problems will
always happen.  To fully avoid it we have to use OE.  For now the
users of toolchain will just have to customize it to fit their own
usage.  I am thinking about dumping the run.* scripts OE generated
along with the source package to solve this but haven't got time to
really look at it.

- John

More information about the community mailing list