[gentoo-dev] RFC: GLEP rap (Prefix/libc)

[heroxbd]

Dear all,

I have made a GLEP draft to standardize our recent effort on using our
own libc from portage inside Prefix.

At present only glibc on linux is supported. While the idea is quite
extensible to other kernel/libc combo. I've got no reply from GLEP team
for 3 weeks. Here I post the draft for peer review.

The rst text are included inline.

Cheers,
Benda

GLEP: XXX
Title: Prefix with libc
Version: 
Last-Modified: 
Author:	Benda Xu <heroxbd@g.o>,
Discussions-To: gentoo-alt@l.g.o
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 20-Jul-2013
Post-History: 


Credits
=======

The work roots in Google Summer of Code 2013 project `Gentoo on
Android`_, mentored by Luca Barbato, and inspired by Ruud Koolen.

Abstract
========

This GLEP provides a solution to have libc within `Gentoo Prefix`_ on
Linux kernel. 


Motivation
==========

Traditionally, Linux variant of Prefix (Prefix Linux) uses the libc
from the host OS. Problems arise when the version of glibc is as old
as 2.5, like RHEL/CentOS 5 and many ancient GNU/Linux still in duty
[#centos5]_ [#fortify]_.  The present solution is to disable automatic
fortify, leaving fortify to be broken [#fortify]_.

The only way to address this issue is to use newer libc from within
Prefix.

RAP
    Literally means *Rap Ain't Prefix*.  It serves as an acronym of
    *Prefix with libc* and is used interchangeably in this GLEP.

Userspace of RAP is identical to Gentoo Linux, therefore more uniform
and robust.  RAP helps the ongoing effort of merging prefix and gx86
portage trees [#pgx86]_.

Thanks to the completely independent userspace, RAP can run on any
kernel that glibc was ported to, giving a full functional GNU
environment in parallel to the host.  Candidates include GNU Hurd,
Google Android (Linux kernel) and BSD (using Debian/kFreeBSD patched
glibc).

Rationale
=========

Gentoo Linux, though often cited as *metadistribution*, originates
from a Linux distribution.  Linux is supported better in Gentoo.  In
Prefix community, the merging of prefix and gx86 portage trees
[#pgx86]_ is brought back by non-Linux systems such as Mac OS X and
Solaris.

To make the effort more incremental, we can decompose the merging into
two stages by first focusing on Prefix Linux.  RAP based Prefix Linux
serves as Stage 1, where only directory prefixes are focused upon.
Kernel-dependent patches for non-Linux are merged at Stage 2.

Exploiting the identical userspace, we can use implicit keywording by
merging presently used Prefix keyword ${ARCH}-linux into ${ARCH},
${ARCH} being `amd64`, `x86`, `arm`, etc.


Backwards Compatibility
=======================

RAP cannot be mixed with present Prefix Linux implementation based on
rpath if version of the host glibc is too low.

ABI is incompatible between, e.g. glibc-2.5 and glibc-2.17, especially
in that dynamic loader of glibc-2.5 cannot load libc.so.6 of
glibc-2.17.

We, however, do not have a complete survey of ABI and header
compatibility across glibc versions.

To coexist with present Prefix Linux, a use flag `rap` is defined in
addition to the `prefix` flag to represent using of libc from within
Prefix.


Specification
=============

Present Prefix Linux uses *rpath mechanism* [#rpath]_, namely encode a
prefixed library path into RPATH and RUNPATH in dynamic section of
ELF.  RAP, on the other hand, encode a prefixed dynamic loader into
INTERP in the program header of ELF.

The dynamic loader is provided by glibc.

RAP is different with present Prefix Linux in toolchain, while
identical in portage tree and portage itself.

Toolchain includes kernel headers(trivial), libc(glibc), compiler(gcc)
and linker(binutils).  We focus our discussion on the last three parts
as well as portage profile to hold things together.

The sysroot features of gcc and binutils are designed for cross
compiling, treating a directory as root of target rootfs.  We make use
of sysroot with adjustments for native use towards our need.


Glibc
-----

Glibc is ready if Prefix support is accepted [#glibcpfx]_.


Gcc
---

Sysroot is used by passing --with-sysroot=${EPREFIX} to econf.  In
addition, the dynamic linker specified by GLIBC_DYNAMIC_LINKER should
be prepended by ${EPREFIX}.


Binutils
--------

Sysroot is used by passing --with-sysroot=${EPREFIX} to econf.  In
addition, the following feature of ld script should be disabled
[#ldinfo]_:

    In case a "sysroot prefix" is configured, and the filename starts
    with the / character, and the script being processed was located
    inside the "sysroot prefix", the filename will be looked for in
    the "sysroot prefix".

Similarly, the feature of prepending sysroot to rpath should also be
disabled.


Portage Profile
---------------

Profile of RAP is put into features/rap, it defines `prefix` and `rap`
keywords.

Arch specific profiles are put into default/linux/${ARCH}/13.0/rap,
and having features/rap as parent.


Implementation
==============

A reference implementation can found at developer `overlay of
heroxbd`_.

The native variant of sysroot feature of binutils and gcc discussed in
this GLEP will be submitted upstream after thorough testing.

References
==========

.. _Gentoo on Android: http://www.awa.tohoku.ac.jp/~benda/projects/android.html

.. _Gentoo Prefix: http://prefix.gentoo.org

.. [#centos5] emerge gcc 4.4.x/4.5.x fails ...,
              http://thread.gmane.org/gmane.linux.gentoo.alt/6110

.. [#fortify] >=sys-devel/gcc-4.3 fails ...,
              https://bugs.gentoo.org/show_bug.cgi?id=289757

.. [#pgx86] Moving prefix/EAPI-3 support into the gentoo-x86 tree,
	    https://bugs.gentoo.org/show_bug.cgi?id=315803

.. [#rpath] gcc/ld wrappers injecting correct flags stuff,
	    http://article.gmane.org/gmane.linux.gentoo.alt/1125

.. [#glibcpfx] sys-libs/glibc Prefix support,
	       https://bugs.gentoo.org/show_bug.cgi?id=473728

.. [#ldinfo] ld Info Section 3.4.2, Commands Dealing with Files

.. _overlay of heroxbd: http://git.overlays.gentoo.org/gitweb/?p=dev/heroxbd.git

.. _Android: http://www.android.com

Copyright
=========

This document has been placed in the public domain.