On Thu, Mar 26, 2009 at 9:27 PM, Patrice Tisserand <[email protected]>wrote:
> From: "Dennis.Yxun" <[email protected]> > 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. em.. this does require deep unstanding about LD linker working mechanism. is SYSROOT is related to cross-toolchain, so hardcoded? not sure whether we still can customize the library search paths. > > > > 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. > > make sense, agree > > > [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). good suggestion > > > Regards, > Patrice. > >
