This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Portable glibc binary package


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

Attachment: signature.asc
Description: Digital signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]