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... ), sys-devel/gcc-config, sys-libs/glibc and profile amd64/with-libc.

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 $BPREFIX/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. 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.


 * emerge binutils-config dependencies first

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.


 * Inspect $EPREFIX/etc/ld.so.conf, and general ld.so.cache


 * In old Prefix, revert back to ld wrapper

replace 1 with a proper alternative.

sys-devel/gcc

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


 * Finally gcc-config

Set Up New Portage

 * Emerge portage with dependence

Disable all use flags to get a minimum portage, PYTHON_TARGETS is required by the new python-r1 eclass. It may fail during to process. Run eselect python when necessary.


 * From now on we will use new portage

and copy over the repo

Finialize

 * startprefix


 * open a new terminal and start fresh


 * We have all the building blocks, the final step goes

followed by

Sit back, have a cup of tea, and watch the marvel emerges.