[oe] cross and staging directories
rpurdie at rpsys.net
Wed Sep 19 10:37:41 CEST 2007
I've been experimenting a bit in Poky to find out exactly why we need
the cross directory.
The motivation for this is the load of files we duplicate in both,
particularly linux-libc-headers, headers from glibc-initial, glibc and
glibc-intermediate and libs from glibc and glibc-intermediate.
If we only install glibc to staging, we could half the run time of
populate_staging for glibc and glibc-intermediate which is a nice
Just not staging the files to cross gives some interesting errors.
Whenever anything tries to link to glibc, you see errors about not being
able to find crti.o and friends. The files are in STAGING_LIBDIR, gcc
just refuses to see them. Poky also demonstrated you also occasionally
see errors about missing header files despite the header files being in
Why does this happen? The compiler's default search directories are
basically broken. Looking at the output from "arm-poky-linux-gnueabi-gcc
So by default it looks in cross for *everything* and has no knowledge of
staging. I ended up reading the gcc source to see what options we have
for injection staging paths into it.
Since crti.o is an internal library, -L options don't cut it. The -B
option does help but you can't use that whilst compiling gcc-cross.
There are various environmental variables you can possibly use but we'd
have to set several to make sure libs, includes and everything else gets
fixed. It felt ugly and I doubt it will work for compiling gcc-cross.
One gcc option which does show potential is the sysroot one. This
happens to solve the libs problem straight off since it adds "/lib/" as
well as "/usr/lib" prefixed by the sysroot and the former happens to
match our staging layout by pure chance. The same trick won't work
for /usr/include though.
The short term solution I've added to poky is to symlink staging from
the cross directories. No need to install twice and the default compiler
paths work. This solves my original objective of not installing things
twice. Personally I don't think these symlinks should have to exist
I am tempted to suggest we start passing the sysroot option to gcc to
get libs working. A symlink from /usr/include to ../include would be a
better cheat than the above symlinks and gets includes working too.
Previous discussions on the subject of sysroot suggest it won't work for
the 3.3 gcc series but we could use the symlink approach from cross to
staging for that.
Agreeing to the above doesn't mean we have to change staging layout but
perhaps it is another indication we should consider it?
More information about the Openembedded-devel