Prefix/libc

This is a project to support libc inside a Prefix. See also Gentoo on Android. A general use case is for Prefix on RHEL 5 (CentOS 5 ans SL 5), where the host glibc-2.5 is too old to support modern features as fortify.

Before this project, Prefix is based on rpath mechanism. The differences are summerized in this table.

Provided a rpath variant of Gentoo Prefix (Prefix-rapth), we can roll out a libc variant Prefix (Prefix-libc) with the following guide. It applies to a Gentoo Prefix on RHEL-5.6 amd64, for other setups it should be similar. Feel free to documents corner cases here.

Using heroxbd's overlay
This is a developer's overlay by heroxbd. The changes will be reviewed and included in the official tree gradually. As of Jun 16, 2013, the overlay includes sys-devel/binutils-config (for injecting --dynamic-linker and for disabling cross-eprefix target library... see below), sys-devel/gcc-config (for a bug fix) and sys-libs/glibc (for Prefix support).

Let's add heroxbd's overlay with Layman from app-portage/layman,

Make sure overlays from layman are effective,

replace /gentoo with your own $EPREFIX.

Details for playing with layman can be found at Layman.

Set Up Environmental Variables
Assume $EPREFIX represents, the new path, Prefix-libc, and $BPREFIX represents, the old path, Prefix-rpath.


 * copy over etc


 * use amd64/with-libc profile

@OVERLAY@ being the overlay of heroxbd, if you got it via layman, it would located at $EPREEFIX/var/lib/layman/heroxbd.
 * clear out unnecessary USE flags in make.conf or package.use. We need a minimal set for bootstrap
 * copy portage data


 * used by portage to override EPREFIX


 * disable collision-protect for bootstrap


 * add PATH of new Prefix


 * clear out gcc toolchain PATH like $EPREFIX/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.2, as it will confuse gcc-config later

Set Up New Toolchain
The host libc (e.g. glibc-2.5 for RHEL 5) might be very old. There are many incompatibilities(e.g. this bug) as time goes. Here we take extra care not to mix new and old toolchain. The process mimics that of building of cross toolchain.

glibc becomes incompatible in both library and include. binutils has to be installed before glibc in that the configure test attempts to load libc.so from new Prefix, which conflict with old ld.so (the dynamic linker). gcc has to be installed after glibc in that it needs to get its internal fixinclude from new glibc in new Prefix during build.

sys-devel/binutils

 * In another terminal, for old prefix, emerge binutils-config from heroxbd's overlay with USE="-dynl -targetlib"

These are two temperary USE flags, -dynl for not injecting --dynamic-linker, -targetlib for preventing libraries in Prefix-libc to be mixed with Prefix-rpath
 * emerge binutils

Verify the new ld dose not have $EPREFIX/{usr/,}lib in runpath.

dependencies first
 * emerge binutils-config

binutils-config which injects dynamic-linker

make sure dynl USE flags is enabled.

sys-libs/glibc

 * Before glibc, some of >=gcc-4.3 dependence library needs to be emerged first, otherwise they will fail during configure because incompatibility of new and old glibc.


 * Our present ld in old Prefix injects runpath into all ELF, which causes assertion failure in glibc. Use raw ld in old Prefix to circumvent this.


 * Off and go.


 * In old Prefix, revert back to ld wrapper if you like

replace 1 with a proper alternative.

sys-devel/gcc

 * Going all the way here, gcc is simple and easy.


 * Finally gcc-config

Set Up New Portage
Now we have a working toolchain, including glibc, armed with sysroot support. Time to unleash the power of portage.


 * In order not to draw in perl, which is hard to bootstrap across Prefix


 * Emerge portage with dependence

Disable all use flags to get a minimum portage, PYTHON_TARGETS is required by the new python-r1 eclass.