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