How can I link to a specific glibc version

Question

When I compile something on my Ubuntu Lucid 10 04 PC it gets linked against glibc  Lucid uses 2 11 of glibc  When I run this binary on another PC with an older glibc  the command fails saying there s no glibc 2 11      As far as I know glibc uses symbol versioning  Can I force gcc to link against a specific symbol version   In my concrete use I try to compile a gcc cross toolchain for ARM

User · Answer

Link with -static  When you link with -static the linker embeds the library inside the executable  so the executable will be bigger  but it can be executed on a system with an older version of glibc because the program will use it s own library instead of that of the system

User · Answer

You are correct in that glibc uses symbol versioning   If you are curious  the symbol versioning implementation introduced in glibc 2 1 is described here and is an extension of Sun s symbol versioning scheme described here  One option is to statically link your binary   This is probably the easiest option  You could also build your binary in a chroot build environment  or using a glibc-new   gt  glibc-old cross-compiler  According to the http   www trevorpounds com blog post Linking to Older Versioned Symbols  glibc   it is possible to to force any symbol to be linked against an older one so long as it is valid by using the same  symver pseudo-op that is used for defining versioned symbols in the first place   The following example is excerpted from the blog post  The following example makes use of glibc   s realpath  but makes sure it is linked against an older 2 2 5 version   include  lt limits h gt   include  lt stdlib h gt   include  lt stdio h gt     asm    quot  symver realpath realpath GLIBC 2 2 5 quot    int main         const char  unresolved    quot  lib64 quot       char resolved PATH MAX 1        if  realpath unresolved  resolved             return 1         printf  quot  s n quot   resolved        return 0

User · Answer

Setup 1  compile your own glibc without dedicated GCC and use it  Since it seems impossible to do just with symbol versioning hacks  let s go one step further and compile glibc ourselves   This setup might work and is quick as it does not recompile the whole GCC toolchain  just glibc   But it is not reliable as it uses host C runtime objects such as crt1 o  crti o  and crtn o provided by glibc  This is mentioned at  https   sourceware org glibc wiki Testing Builds action recall amp rev 21 Compile against glibc in an installed location Those objects do early setup that glibc relies on  so I wouldn t be surprised if things crashed in wonderful and awesomely subtle ways   For a more reliable setup  see Setup 2 below   Build glibc and install locally   export glibc install    pwd  glibc build install   git clone git   sourceware org git glibc git cd glibc git checkout glibc-2 28 mkdir build cd build    configure --prefix   glibc install  make -j  nproc  make install -j  nproc    Setup 1  verify the build  test glibc c   define  GNU SOURCE  include  lt assert h gt   include  lt gnu libc-version h gt   include  lt stdatomic h gt   include  lt stdio h gt   include  lt threads h gt   atomic int acnt  int cnt   int f void  thr data        for int n   0  n  lt  1000    n              cnt            acnt            return 0     int main int argc  char   argv           Basic library version check         printf  gnu get libc version      s n   gnu get libc version             Exercise thrd create from -pthread         which is not present in glibc 2 27 in Ubuntu 18 04         https   stackoverflow com questions 56810 how-do-i-start-threads-in-plain-c 52453291 52453291        thrd t thr 10       for int n   0  n  lt  10    n          thrd create  amp thr n   f  NULL       for int n   0  n  lt  10    n          thrd join thr n   NULL       printf  The atomic counter is  u n   acnt       printf  The non-atomic counter is  u n   cnt       Compile and run with test glibc sh      usr bin env bash set -eux gcc     -L    glibc install  lib      -I    glibc install  include      -Wl --rpath    glibc install  lib      -Wl --dynamic-linker    glibc install  lib ld-linux-x86-64 so 2      -std c11     -o test glibc out     -v     test glibc c     -pthread     ldd   test glibc out   test glibc out   The program outputs the expected   gnu get libc version     2 28 The atomic counter is 10000 The non-atomic counter is 8674   Command adapted from https   sourceware org glibc wiki Testing Builds action recall amp rev 21 Compile against glibc in an installed location but --sysroot made it fail with   cannot find  home ciro glibc build install lib libc so 6 inside  home ciro glibc build install   so I removed it   ldd output confirms that the ldd and libraries that we ve just built are actually being used as expected     ldd test glibc out         linux-vdso so 1  0x00007ffe4bfd3000          libpthread so 0   gt   home ciro glibc build install lib libpthread so 0  0x00007fc12ed92000          libc so 6   gt   home ciro glibc build install lib libc so 6  0x00007fc12e9dc000           home ciro glibc build install lib ld-linux-x86-64 so 2   gt   lib64 ld-linux-x86-64 so 2  0x00007fc12f1b3000    The gcc compilation debug output shows that my host runtime objects were used  which is bad as mentioned previously  but I don t know how to work around it  e g  it contains   COLLECT GCC OPTIONS  usr lib gcc x86 64-linux-gnu 7          x86 64-linux-gnu crt1 o   Setup 1  modify glibc  Now let s modify glibc with   diff --git a nptl thrd create c b nptl thrd create c index 113ba0d93e  b00f088abb 100644 --- a nptl thrd create c     b nptl thrd create c    -16 11  16 14        License along with the GNU C Library  if not  see      lt http   www gnu org licenses  gt          include  lt stdio h gt      include  thrd priv h    int  thrd create  thrd t  thr  thrd start t func  void  arg        puts  hacked        Static assert  sizeof  thr     sizeof  pthread t                       sizeof  thr     sizeof  pthread t       Then recompile and re-install glibc  and recompile and re-run our program   cd glibc build make -j  nproc  make -j  nproc  install   test glibc sh   and we see hacked printed a few times as expected   This further confirms that we actually used the glibc that we compiled and not the host one   Tested on Ubuntu 18 04   Setup 2  crosstool-NG pristine setup  This is an alternative to setup 1  and it is the most correct setup I ve achieved far  everything is correct as far as I can observe  including the C runtime objects such as crt1 o  crti o  and crtn o   In this setup  we will compile a full dedicated GCC toolchain that uses the glibc that we want   The only downside to this method is that the build will take longer  But I wouldn t risk a production setup with anything less   crosstool-NG is a set of scripts that downloads and compiles everything from source for us  including GCC  glibc and binutils   Yes the GCC build system is so bad that we need a separate project for that   This setup is only not perfect because crosstool-NG does not support building the executables without extra -Wl flags  which feels weird since we ve built GCC itself  But everything seems to work  so this is only an inconvenience   Get crosstool-NG and configure it   git clone https   github com crosstool-ng crosstool-ng cd crosstool-ng git checkout a6580b8e8b55345a5a342b5bd96e42c83e640ac5 export CT PREFIX    pwd   build install  export PATH   usr lib ccache   PATH     bootstrap   configure --enable-local make -j  nproc    ct-ng x86 64-unknown-linux-gnu   ct-ng menuconfig   The only mandatory option that I can see  is making it match your host kernel version to use the correct kernel headers  Find your host kernel version with   uname -a   which shows me   4 15 0-34-generic   so in menuconfig I do    Operating System   Version of linux    so I select   4 14 71   which is the first equal or older version  It has to be older since the kernel is backwards compatible   Now you can build with   env -u LD LIBRARY PATH time   ct-ng build CT JOBS  nproc    and now wait for about thirty minutes to two hours for compilation   Setup 2  optional configurations  The  config that we generated with   ct-ng x86 64-unknown-linux-gnu has   CT GLIBC V 2 27 y   To change that  in menuconfig do    C-library Version of glibc   save the  config  and continue with the build   Or  if you want to use your own glibc source  e g  to use glibc from the latest git  proceed like this    Paths and misc options   Try features marked as EXPERIMENTAL  set to true  C-library   Source of glibc   Custom location  say yes Custom location   Custom source location  point to a directory containing your glibc source      where glibc was cloned as   git clone git   sourceware org git glibc git cd glibc git checkout glibc-2 28   Setup 2  test it out  Once you have built he toolchain that you want  test it out with      usr bin env bash set -eux install dir    CT PREFIX  x86 64-unknown-linux-gnu  PATH    PATH    install dir  bin      x86 64-unknown-linux-gnu-gcc     -Wl --dynamic-linker    install dir  x86 64-unknown-linux-gnu sysroot lib ld-linux-x86-64 so 2      -Wl --rpath    install dir  x86 64-unknown-linux-gnu sysroot lib      -v     -o test glibc out     test glibc c     -pthread     ldd test glibc out   test glibc out   Everything seems to work as in Setup 1  except that now the correct runtime objects were used   COLLECT GCC OPTIONS  home ciro crosstool-ng  build install x86 64-unknown-linux-gnu bin    x86 64-unknown-linux-gnu sysroot usr lib    lib64 crt1 o   Setup 2  failed efficient glibc recompilation attempt  It does not seem possible with crosstool-NG  as explained below   If you just re-build   env -u LD LIBRARY PATH time   ct-ng build CT JOBS  nproc    then your changes to the custom glibc source location are taken into account  but it builds everything from scratch  making it unusable for iterative development   If we do     ct-ng list-steps   it gives a nice overview of the build steps   Available build steps  in order    - companion tools for build   - companion libs for build   - binutils for build   - companion tools for host   - companion libs for host   - binutils for host   - cc core pass 1   - kernel headers   - libc start files   - cc core pass 2   - libc   - cc for build   - cc for host   - libc post cc   - companion libs for target   - binutils for target   - debug   - test suite   - finish Use   lt step gt   as action to execute only that step  Use    lt step gt   as action to execute up to that step  Use   lt step gt    as action to execute from that step onward    therefore  we see that there are glibc steps intertwined with several GCC steps  most notably libc start files comes before cc core pass 2  which is likely the most expensive step together with cc core pass 1   In order to build just one step  you must first set the  Save intermediate steps  in  config option for the intial build    Paths and misc options   Debug crosstool-NG   Save intermediate steps     and then you can try   env -u LD LIBRARY PATH time   ct-ng libc  -j nproc    but unfortunately  the   required as mentioned at  https   github com crosstool-ng crosstool-ng issues 1033 issuecomment-424877536     Note however that restarting at an intermediate step resets the installation directory to the state it had during that step  I e   you will have a rebuilt libc - but no final compiler built with this libc  and hence  no compiler libraries like libstdc   either     and basically still makes the rebuild too slow to be feasible for development  and I don t see how to overcome this without patching crosstool-NG   Furthermore  starting from the libc step didn t seem to copy over the source again from Custom source location  further making this method unusable   Bonus  stdlibc    A bonus if you re also interested in the C   standard library  How to edit and re-build the GCC libstdc   C   standard library source

User · Answer

In my opinion  the laziest solution  especially if you don t rely on latest bleeding edge C C   features  or latest compiler features  wasn t mentioned yet  so here it is  Just build on the system with the oldest GLIBC you still want to support  This is actually pretty easy to do nowadays with technologies like chroot  or KVM Virtualbox  or docker  even if you don t really want to use such an old distro directly on any pc  In detail  to make a maximum portable binary of your software I recommend following these steps   Just pick your poison of sandbox virtualization     whatever  and use it to get yourself a virtual older Ubuntu LTS and compile with the gcc g   it has in there by default  That automatically limits your GLIBC to the one available in that environment   Avoid depending on external libs outside of foundational ones  like  you should dynamically link ground-level system stuff like glibc  libGL  libxcb X11 wayland things  libasound libpulseaudio  possibly GTK  if you use that  but otherwise preferrably statically link external libs ship them along if you can  Especially mostly self-contained libs like image loaders  multimedia decoders  etc can cause less breakage on other distros  breakage can be caused e g  if only present somewhere in a different major version  if you statically ship them    With that approach you get an old-GLIBC-compatible binary without any manual symbol tweaks  without doing a fully static binary  that may break for more complex programs because glibc hates that  and which may cause licensing issues for you   and without setting up any custom toolchain  any custom glibc copy  or whatever

[linux] How can I link to a specific glibc version?

Examples related to linux

Examples related to gcc

Examples related to linker

Examples related to glibc

Examples related to libc