Re: Portable glibc binary package

[Shaun Jackman <sjackman at gmail dot com>]

On Thu, 12 Mar 2015 at 23:45 Mike Frysinger <vapier@gentoo.org> wrote:
>
> On 28 Oct 2014 11:34, Shaun Jackman wrote:
> > I'd like compile and distribute a binary glibc package that can be
> > installed in a user's home directory. High performance computing
> > systems are notorious for running decade-old distributions of Linux,
> > which makes it difficult to compile and run modern software, and
> > almost impossible to run binary executables from elsewhere. To update
> > glibc, I've had fantastic luck building glibc from source and
> > installing in a home directory. I'd like now to compile and distribute
> > a binary package of glibc for Linuxbrew (http://brew.sh/linuxbrew/),
> > called a bottle in Homebrew terminology
> > (https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/Bottles.md).
> >
> > I feel like this portability would be technically possible if glibc
> > were compiled with --prefix=/ and then at run time determined its
> > prefix (relative to the libc.so.6 loaded by the dynamic interpreter)
> > and then added that prefix to all glibc files it accessed: other glibc
> > solibs, localization, config files, and so on.
> >
> > This feature would be quite useful to me. Does it sound interesting
> > and/or useful to anyone else? How much work do you think it would be
> > to implement? Is there a simpler solution?
>
> the problem isn't really with glibc itself.  it's with all the programs
> you want to use the custom glibc.
>
> the way dynamically linked ELFs work is that every single one has a path
> hardcoded to the ldso that is needed at runtime:
> $ readelf -l /bin/sh | grep -i interpr
>       [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
>
> when you exec an ELF, the kernel reads the interpreter path out of it
> (PT_INTERP), and then transparently loads that ELF instead, passing it
> information about the original ELF.  then that ldso takes care of
> everything else.
>
> currently the ldso has paths hardcoded into it to search for library
> and config files and code do so more dynamically, but if that very
> first step isn't handled automatically, i'm not sure improving the
> ldso is worth the time.
>
> unless, in addition to the custom glibc, you're also compiling and
> distiributing custom programs that use that custom glibc ?
>
> crazy idea: what if the hardcoded paths in the ldso used $ORIGIN ...
> then things would "just" work ?
>
> less crazy idea: include a bootstrap wrapper shell script for every
> executable file.  this is what the lddtree project i wrote does.  it
> is a bit hacky, but it actually works.
>
> $ lddtree --copy-to-tree /tmp/foo --generate-wrappers /bin/bash
> $ tree /tmp/foo/
> /tmp/foo/
> /tmp/foo/
> |-- bin
> |   |-- bash
> |   `-- bash.elf
> `-- lib64
>     |-- ld-linux-x86-64.so.2
>     |-- libc.so.6
>     |-- libhistory.so.6
>     |-- libncurses.so.5
>     `-- libreadline.so.6
> $ cat /tmp/foo/bin/bash
> #!/bin/sh
> if ! base=$(realpath "$0" 2>/dev/null); then
>   case $0 in
>   /*) base=$0;;
>   *)  base=${PWD:-`pwd`}/$0;;
>   esac
> fi
> basedir=${base%/*}
> exec \
>   "${basedir}/../lib64/ld-linux-x86-64.so.2" \
>   --library-path "${basedir}/../lib64" \
>   --inhibit-rpath '' \
>   "${base}.elf" \
>   "$@"
> -mike


Hi, Mike.

I've got the programs that use the custom glibc figured out. I compile
programs with -Wl,--dynamic-linker and -Wl,-rpath [1]. That part works
fine. To install executables compiled elsewhere, I use patchelf to set
the above two variables.

My original question remains: is it possible to compile a portable
glibc binary package that can be installed in a user's home directory?

Cheers,
Shaun

[1] https://github.com/Homebrew/linuxbrew/blob/master/Library/Homebrew/extend/ENV/std.rb#L62