| 1 |
Dear Ruud,
|
| 2 |
|
| 3 |
Ruud Koolen <redlizard@×××××××××.nl> writes:
|
| 4 |
|
| 5 |
>> Though we could patch gcc headers to redefine the default standard run time |
| 6 |
>> linker location, the same ld-wrapper mechanism can be used to inject things |
| 7 |
>> like "–dynamic-linker=${EPREFIX}/lib/ld-linux.so.2". The latter solution |
| 8 |
>> will make switching between rpath and prefix-libc variants of Gentoo Prefix |
| 9 |
>> easier. |
| 10 |
> |
| 11 |
> Note that gentoo-prefix-libc also has different settings on the compiler |
| 12 |
> itself, like not having /usr/include in the default include path. Switching |
| 13 |
> linker configurations will not change that. |
| 14 |
|
| 15 |
Got it.
|
| 16 |
|
| 17 |
The present solution of prepending EPREFIX header to /usr/include could
|
| 18 |
be enough IMHO. The necessary header would be drawn in via
|
| 19 |
dependency. By making use of /usr/include, GCC from EPREFIX is more
|
| 20 |
useful, isn't it?
|
| 21 |
|
| 22 |
>> It could be hard to bootstrap Gentoo Prefix on Android. One possible way is |
| 23 |
>> to install a native full distribution and then bootstrap a Gentoo Prefix |
| 24 |
>> with libc. We could distribute precompiled Gentoo Prefix on Google Play for |
| 25 |
>> the general public. |
| 26 |
> |
| 27 |
> Zero_Chaos bootstrapped his install by first unpacking a plain gentoo tarball |
| 28 |
> into a chroot, and bootstrapping prefix(-libc) from within that chroot. |
| 29 |
> Afterwards, the prefix install could be moved out of the chroot. |
| 30 |
|
| 31 |
That's cool :D Let me add this.
|
| 32 |
|
| 33 |
>> redlizard's gentoo-prefix-libc has cross bootstraping in mind, with the hope |
| 34 |
>> of running uclibc-based Gentoo Prefix on Android. The details, however, |
| 35 |
>> still call for much effort. |
| 36 |
> |
| 37 |
> While the local-libc architecture allows for arbitrary cross compilation |
| 38 |
> bootstraps, the current gentoo-prefix-libc bootstrap script only works for |
| 39 |
> cross compilations to architectures runtime compatible with the host -- amd64 |
| 40 |
> to x86, arm hardfp to arm softfp, etc. In other words, the host processor |
| 41 |
> should still be able to run the target executables. |
| 42 |
|
| 43 |
I see. glibc to uclibc, too ;)
|
| 44 |
|
| 45 |
> This can be changed to support real cross compilation, but this will |
| 46 |
> probably be a nontrivial addition. |
| 47 |
|
| 48 |
Yeah, that's the point.
|
| 49 |
|
| 50 |
>> It would be very nice if crossdev could produce cross toolchain in Gentoo |
| 51 |
>> Prefix by a single command. |
| 52 |
> |
| 53 |
> I tried the same, and accomplishing this would make the bootstrap process a |
| 54 |
> whole lot easier. It would basically reduce the bootstrap-prefix.sh process |
| 55 |
> to: |
| 56 |
> |
| 57 |
> - Manually bootstrap stage1 tools into some temporary directory |
| 58 |
> (${EPREFIX}/tmp). |
| 59 |
> - Manually bootstrap portage into ${EPREFIX}/tmp (!). |
| 60 |
> - Manually bootstrap crossdev into ${EPREFIX}/tmp. |
| 61 |
> - Use crossdev to build a cross compiler that targets the desired architecture |
| 62 |
> (which need not be runtime-compatible with the host architecture!) |
| 63 |
> - env PORTAGE_OVERRIDE_EPREFIX=${EPREFIX} emerge -e @system. |
| 64 |
|
| 65 |
We don't need to mix crossdev with bootstrap process, nor two bootstrap
|
| 66 |
processes. bootstrap-prefix.sh is less robust than portage. Instead,
|
| 67 |
|
| 68 |
1. bootstrap Gentoo Prefix on amd64
|
| 69 |
2. with crossdev, cross bootstrap Gentoo Prefix for arm.
|
| 70 |
|
| 71 |
is easier.
|
| 72 |
|
| 73 |
Cheers,
|
| 74 |
Benda |
Archives