ld.so alternatives

Question

I need to make my linux executable "compile once, run everywhere". Theoretically it's possible, because my program only use very basic system calls (system calls for network IO and file IO). In practice, it's a different story:

My developing platform is Ubuntu 12.04, which has pretty recent kernel, glibc and toolchain. I first tried to static link my executable, but the executable refuses to run on centos 5 (kernel version 2.6.18). If the executable is dynamic linked, the dynamic loader (ld.so) refuses to load my executable. I even tried to ship a modified dynamic loader (I modified it to ignore kernel version), libc, libgcc_s, still doesn't work, because the modified loader always tries to load the libc from the system and ignore the libc shipped along with my executable.

I need a dynamic loader which would blindly load everything I want it to load. Anyone knows such a dynamic loader on linux ? I'm not sure whether I'm heading to the right direction, so any suggestion is welcome.

Lir

Did you try musl-libc.org ? It might perhaps solve the issue (but maybe not); if it does, tell us... – Hoodoo

Did you try also to strace the failing execution of the statically linked program on Centos 5? You'll understand better what is failing... – Hoodoo

I have read the source code of glibc, the statically linked libc would check the version of the running kernel, and simply exit if the running kernel version is too low. – Lir

Just checked musl-libc. This is from its official FAQ: "At present, some glibc-linked shared libraries can be loaded with musl, but all but the simplest glibc-linked applications will fail if musl is dropped-in in place of /lib/ld-linux.so.2.". Basically it means I need to build libstdc++ against musl-libc, because my program is written in C++. Haven't found much information about the stability of "musl libstdc++ combination". – Lir

Answer 1

please check

http://sourceforge.net/projects/html5remote/

In this project I played around with patchElf, LD_PRELOAD and LD_LIBRARY_PATH.

There are some tricks to make relative paths working. After some experiments I came to the conclusion that patching the target binary is not necessary because the ld.so can be used to load the target program directly from the command line, ex:

$ /lib64/ld-linux-x86-64.so.2 [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]

In this case the interpreter written in the elf header of the target binary is ignored, ex:

$ ldd /usr/bin/mysql

    linux-vdso.so.1 =>  (0x00007fff3fde0000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f72f89ea000)
    libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 (0x00007f72f87a8000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f72f8590000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f72f838c000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f72f8090000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f72f7cd0000)
    /original/path/to/ld.so (0x00007f72f9187000) ** ignored **
    libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f72f7aa9000)

The option:

--library-path

tells to the ld.so loader where to search for the shared libraries (ex: libc.so, etc..)

I hope this can help :)

Cleodell

Answer 2

Try using CentOS 5 as your build machine, and running that executable on newer platforms instead of the other way around.

Mcnair

I don't want to use centos 5 as the developing machine, too old for daily use. Also don't like to build on centos 5 and debug on a different one, inconvenient. – Lir

You definitely could install centos 5 in a chroot-ed environment on your developing machine. – Hoodoo

Answer 3

Just make your binaries more portable.

You can,

• target Linux Software Base (LSB) ABI:
  • http://www.linuxfoundation.org/collaborate/workgroups/lsb
  • https://wiki.linuxfoundation.org/en/Book/BinaryCompatibility
• Use a virtual machine with the oldest Linux distribution you want to support
  • https://mcmap.net/q/393352/-how-do-i-build-an-app-for-an-old-linux-distribution-and-avoid-the-fatal-kernel-too-old-error
• Craft your binaries
  • http://stevehanov.ca/blog/index.php?id=97
  • http://www.evanjones.ca/portable-linux-binaries.html
  • http://www.pixelbeat.org/programming/linux_binary_compatibility.html

Regards.

Grille