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