Re: [gentoo-embedded] Trying to Make Cross compile more firendly

[Dennis.Yxun]

On Thu, Mar 26, 2009 at 9:27 PM, Patrice Tisserand <ptisserand@××××××.com>wrote:

> From: "Dennis.Yxun" <dennis.yxun@×××××.com>
> 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.
>
>