Prefix/libc

This is a project to support libc inside a Prefix, so call "RAP" (Rap Ain't Prefix). See also Project: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/rap 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

 * emerge binutils

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


 * emerge binutils-config dependencies first

Symlink the bash from old Prefix

binutils-config

sys-libs/glibc

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


 * A minimal python is needed for portage. Notice the python version should be the same in both EPREFIX and BPREFIX, otherwise compatibility issues may happen, like python-2.7.5 vs python-2.7.3.


 * 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

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


 * Emerge portage


 * 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.