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] |
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] |