From: "Dennis.Yxun" <dennis.yxun@...>
Subject: [gentoo-embedded] Trying to Make Cross compile more firendly
Date: Thu, 26 Mar 2009 14:59:06 +0000
Hi Dennis,
> HI Community:
> I'm trying to cross compile a stage1 base system for Openpandora. All the
> steps can be followed in this wiki [1].
Thanks for the link.
[cut]
> Actually the upstream provide two scripts [2] to setup the building
> environment. Which one is crossdev_set_environment.sh, it set SYSROOT same
> with ROOT, another is set_environment.sh, which make ROOT different from
> SYSROOT. Since SYSROOT is the cross
> toolchain's environment, and ROOT is the target rootfs. I perfer to take
> set_set_environment.sh's way, It would seperate toolchains and target
> rootfs. So it will make the finanal rootfs more neat and clean, also will
> avoid potential file confliction. That could be possible, for example
> the linux-headers, both cross toolchain and target rootfs will emerge. Also
> maybe simply mark it as provided would solve this problem.
If you use a ROOT different of SYSROOT, you could have some issue with ld linker
script.
If you look at content of libc.so linker script, you will something like:
GROUP (/lib/libc.so.6 ...)
According to http://sourceware.org/binutils/docs/ld/File-Commands.html , it will
work when this file is in sysroot but not when out of the sysroot.
I have found there is a least the libc.so and libpthread.so linker script which
have this issue.
But maybe the same issue could be present in other linker script.
> The upstream's default embedded's make.conf only look for header files and
> library from ROOT's path. So if some lowlevel package
> looking for header file or library located at the toolchain's path, will fail
> at complile stage. I come cross and idea, maybe it's possible to add
> both SYSROOT and ROOT's path into compiler's looking path.So I just tweaked
> the CFLAGS and LDFLAGS[3]. I have no idea whill there be
> any problem with this. Still struggling and so far I got here.
I don't think it's necessary to add SYSROOT in headers and libraries search
path, since gcc already looking in his sysroot.
> [3] LDFLAGS=" -L${ROOT}/lib -L/${ROOT}/usr/lib \
> -L${SYSROOT}usr/lib -L${SYSROOT}lib \
> "
> CFLAGS="-Os -pipe ${MARCH_TUNE} -fomit-frame-pointer \
> -I${SYSROOT}/usr/include \
> -I${SYSROOT}/include \
> -I${ROOT}usr/include/ \
> -I${ROOT}include/ \
> "
For CFLAGS, I think it's better to replace -I${ROOT}/usr/include by -isystem
${ROOT}/usr/include
If in a sofware source code you have a fle name features.h, some #include
"features.h" and of course a -I. in his compilation CFLAGS.
If your CFLAGS are appending to the sofware CFLAGS, it's fine.
But if your CFLAGS are prepending to the software CFLAGS, it will use the first
features.h found in -I directories.
With -isystem this issue only occurs if in the compilation CFLAGS there is also
a -isystem (which is quite unusual I think).
Regards,
Patrice.
|
