Prefix/libc

This is a project to support libc inside a Prefix, codenamed 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. Practically, you can on say SGI Irix install a Gentoo Linux in some location, for example in /scratch/gentoo. This path where you want to have your relocated installation is stored in ${EPREFIX} variable. You will get all files installed in ${EPREFIX}/{bin,etc,lib,tmp,usr,var}, etc.

Classical Prefix is based on rpath but it does not give you the freedom having your own sys-libs/glibc, supposedly a recent-one (you must stay with glibc provided by the host operating system). Many packages in Gentoo Linux will not compile against archaic glibc, say 2.13. Many utilites need at least 2.17. Also binary packages like Oracle java-1.8 JRE/SDK need more recent glibc. Java IcedTea-3.2.0 needs 2.14.

So then there is a Prefix/libc (sysroot method, called Gentoo::RAP).

Finally, at some point there will be another implementation of Prefix/libc approach (native paths method, experimental). It is developed by @redlizard. In the future it will be merged with Prefix/libc (sysroot method, aka Gentoo::RAP).

In terms of source repositories, Gentoo::Prefix uses its own portage tree. This overlay contains packages that we need, or modifications that aren't yet finalised/merged with the main gentoo tree. However, Gentoo Prefix users need a way to update their trees. Since the Prefix tree is a union of the main gentoo tree, overlaid with the prefix overlay, this is non-trivial to obtain (like e.g. git clone). One simply needs rsync generation. The scripts for this can be found in the scripts dir of the prefix overlay. Gentoo infra doesn't want to run this for us. They said in the past they did want to, for us, but never got back, or only want to do it in a simply way (e.g. the git clone/pull).

Gentoo::RAP uses the main Gentoo x86 portage tree so you get more recent packages. However, there is usually a small set of altyered ebuilds, patches and eclasses in a RAP overlay.

Gentoo::Prefix portage tree from Fabian has many patches but the package versions are quickly outdated compared to the main repo. In contrary, Gentoo::RAP tries to override only some classes from the bare Gentoo code base and simply relies on the latest and greatest portage tree. Of note, bash package has some overrrides, time to time pushed into the main gentoo-x86 repo. In summary, on Gentoo::RAP you might hit programming errors in ebuilds and eclasses which Fabian already discovered and fixed in his Gentoo Prefix repo.

Both bootstrap scripts will fetch quite a lot of tarball data, with the portage tree, with package sources. There is no easy way to pre-fetch all the stuff you will need beforehand, and be off-line during compilation. Watch for improvements.

Bug reports in Gentoo::Prefix have a separate category at bugs.gentoo.org while Gentoo::RAP issues can go along all other bug report tagged as "Current packages". Current issues with mostly ebuilds not respecting $EPREFIX variable can be seen here: https://bugs.gentoo.org/buglist.cgi?quicksearch=EPREFIX&list_id=3399810. Some might be already fixed in Fabian's tree.

bootstrap-rap.sh will nicely copy /etc/{passwd,hosts} from the host system setup, while bootstrap.sh is not that advanced. Well, read on that at the end of this document, it is not needed because Gentoo::Prefix does not provide the separate/additional glibc.

The differences between the three approaches are summarized in this table.

Installation
Download the Gentoo RAP bootstrap-rap.sh. You can use various ways to obtain the script and get it to a place where you can execute it. Once in position, preform the following commands:

That's all! The script will guide you through the full process, and tells you how to start your freshly bootstrapped Gentoo RAP system if it successfully runs up till the end. In normal cases, you don't need any more than just this.

Manual Installation
RAP can also be installed manually as:

Refer to Prefix/Manual_Bootstrap for more details.

Tested distributions
At the moment, RAP supports Linux distributions only. The following tables tracks the tested distributions with the script. Feel free to add your own.

Compile inside memory
On a cluster node with large memory and shared network filesystem, compiling in a memory tmpfs can be significantly faster. /dev/shm is mounted as tmpfs by many distributions. For example:

Before calling bootstrap-rap.sh, it can be done with:

On systemd/RedHat systems tmpfs (shm) is mounted by default on /tmp IIRC, /dev/shm doesn't exist any more there (at least when I was toying with CO7/OL7).

Add an en_US.UTF-8 locale
We are having our own libc, the locales should be generated in Prefix. Add an entry to EPREFIX/etc/locale.gen

Then generate the locale by:

For more details, refer to the handbook.

Use a nearby mirror
The bootstrap script needs to download quite a bit. It can be accelerated by using a Gentoo mirror nearby. To use a mirror, GENTOO_MIRRORS should be set both in the environment

And make.conf:

Replace http://mirrors.tuna.tsinghua.edu.cn/gentoo with a favorite mirror.

For more details, refer to the GENTOO_MIRRORS article.

The rsync mirror is set in repos.conf:

Replace rsync://mirrors.tuna.tsinghua.edu.cn/gentoo-portage with your favorite mirror. Refer to /etc/portage/repos.conf repos.conf for details. Instead of remember to use.

Troubleshooting
RAP is expected to run on a wild variety of environments. Let's document here the problems met during the bootstrap and the solutions made.

It is very funny to see how many host systems are badly screwed.

/bin/tar exists but does not work. The working one is in /usr/local/bin
Solution: edit the script to prepend /usr/local/bin to PATH.

Username becomes invalid inside RAP
RAP has its own glibc, which performs independent name service from the host. The uid to username mapping is managed by nss of glibc. If we install a new glibc, we are making a new set of mappings. That is not needed to be done by the Gentoo::Prefix approach (which does not provide a separate glibc).

The bootstrap script first tries to generate passwd and group from getent and links host /etc/{passwd,group} as fallback,

If usernames are provided by LDAP, sometimes it is configured so that a normal user cannot query the entire passwd or group by getent. In that case portage breaks, will not be able to resolve the username and group. An quick fix is to show yourself to Prefix by specifying who you are,

But other uses on the host cannot be resolved. To get a fair sample of all users on the system, enumerate the /home directory,

Another solution is to use host nss_ldap library. (nss is part of glibc, which resolves uid/gid.)

Then set nsswitch to query ldap.

FAQ
What is Gentoo:Prefix not good for?

You will have problem running java binaries, even the Oracle jre/jdk packages contain some binary code which needs I think >=glib-2.17. If your host glibc is older, you are out of luck with getting some key parts of java environment installed on Gentoo::Prefix. Gentoo::Prefix has no multilib support so forget about running a 32bit Adobe acroread through it (although Gentoo::RAP also lacks 32bit support).

Can Gentoo::RAP execute 32bit and 64bit binaries (aka having multilib support)?

No, the profile used in it is amd64-oly.

The profile we are using is not multilib. Sometime before we thought bootstrapping another Prefix makes more sense if x86 is needed. Seems that we should revisit this, to test out multilib.

Any pressing issue with Gentoo::RAP?

Java support. You have to patch manually $EPREFIX/usr/portage/eclass/java-utils-2.eclass from. Because the file does not belong to any package it will be overwritten by the not yet fixed file from portage tree, so after every 'emerge --sync' you have to reapply the patch. Although in general portage tree is updated using 'emerge --sync', on Gentoo::RAP you should use 'emaint sync -r rap' instead. Benda Xu said both approaches do the same but but act on different directory trees. You will realize once you want to apply the above mentioned java patch:

The first file still needs to be patched while the second is already patched by Benda Xu. So, 'emerge --sync' updates a portage tree copy in /apps/gentoo/usr/portage/ whereras 'emaint sync -r rap' updates /apps/gentoo/usr/portage-stage/ instead. Now figure out which one is actually used in your installation. ;-)

Further, most apps using java-config and Apache ant still have issues. But it would be only worse if you tried Gentoo::Prefix instead (you would not get even that far).

Perl support. There is likely a general Prefix-related issue in some perl-related eclass or my own programming style issue. Many perl-based packages do not install because of 'Aborting due to QA concerns: double prefix files installed' (sci-biology/TransDecoder-2.1.0::science and many other). See.

Can I emerge myself glibc on Prefix?

If I remember no but Fabian claims it should be possible. However, it will be ignored anyways by the binaries and your binaries will anyway use host's glibc (supposedly an old one).

Are there any other special=difficult libs, like iconv, icu, readline, or is only glibc being the main problem?

Seems you can install all these on Gentoo::Prefix except the glibc.

Can I switch from Gentoo:Prefix to RAP?

No idea, probably not.

Can I switch from RAP to the third thingie ("Prefix/libc (native paths method, experimental)"), whatever that does?

Will be merged into RAP, once fully working.

Can I move binaries to another host?

It sounds one can understand that the binaries with -rpath compiled in may not work on another system unless LD_LIBRARY_PATH redirects the paths, but what about Gentoo:RAP binaries. Can they be moved? Could I check something in the binaries using "ldd or some elfutils program" to learn more? They use a modified loader with a hardcoded path, so only if you put them into very same place?

Install elfutils on the hosting operating system. See for example: