Linking to library using alternate path (/lib64 instead of /lib)

Malvineous · 2012-02-26 01:03:06

Hi all,

I'm using Arch 64-bit to compile a program into a binary for other Linux distributions. Unfortunately it seems that Arch stores the dynamic library loader in /lib/ld-linux-x86-64.so.2 (the path to which then gets hard-coded into my binary) however other distributions seem to follow the Linux Standard Base which says it must be stored in /lib64 instead.

Arch does have a symlink in /lib64 so it can run binaries compiled on other distros, but I've discovered the other distros don't have a matching symlink in /lib. This means Arch will run binaries compiled anywhere, but binaries compiled on Arch won't run on other distros.

Does anyone know how to tell the compiler (or even better, a ./configure script) to link to the symlink in /lib64 instead of the actual file in /lib?

falconindy · 2012-02-26 01:34:02

I'm not aware of a way to do this at build time, but a program like patchelf can modify the interpreter location after the fact.

I would be very wary of compiling on Arch for other distros, mostly due to the fact that our glibc package is going to be newer. Versioned symbols mean that you're going to run into severe problems with any target system running glibc earlier than 2.14 (mempcy was reversioned). Looking at the last 3 releases, that seems to be the worst of it, but fwiw...

$ readelf -s /lib/libc.so.6 | grep GLIBC_2\.15
   286: 00000000000f7770    30 FUNC    GLOBAL DEFAULT   12 __fdelt_warn@@GLIBC_2.15
   348: 00000000000f7770    30 FUNC    GLOBAL DEFAULT   12 __fdelt_chk@@GLIBC_2.15
   483: 00000000000e31b0    22 FUNC    WEAK   DEFAULT   12 process_vm_writev@@GLIBC_2.15
   526: 00000000000b0760   436 FUNC    GLOBAL DEFAULT   12 scandirat@@GLIBC_2.15
  1102: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  ABS GLIBC_2.15
  1519: 00000000000d53d0    21 FUNC    GLOBAL DEFAULT   12 posix_spawn@@GLIBC_2.15
  1765: 00000000000e31b0    22 FUNC    WEAK   DEFAULT   12 process_vm_readv@@GLIBC_2.15
  1921: 00000000000b0760   436 FUNC    WEAK   DEFAULT   12 scandirat64@@GLIBC_2.15
  1961: 00000000000d53f0    21 FUNC    GLOBAL DEFAULT   12 posix_spawnp@@GLIBC_2.15
  6163: 00000000000d53d0    21 FUNC    GLOBAL DEFAULT   12 posix_spawn@@GLIBC_2.15
  6820: 00000000000d53f0    21 FUNC    GLOBAL DEFAULT   12 posix_spawnp@@GLIBC_2.15
  7417: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  ABS GLIBC_2.15

$ readelf -s /lib/libc.so.6 | grep GLIBC_2\.14
    74: 00000000000e29f0    37 FUNC    GLOBAL DEFAULT   12 clock_adjtime@@GLIBC_2.14
   515: 00000000000e30f0    40 FUNC    GLOBAL DEFAULT   12 name_to_handle_at@@GLIBC_2.14
   967: 00000000000e3180    37 FUNC    GLOBAL DEFAULT   12 setns@@GLIBC_2.14
   981: 00000000000e3120    94 FUNC    GLOBAL DEFAULT   12 open_by_handle_at@@GLIBC_2.14
  1094: 00000000000e3af0   157 FUNC    GLOBAL DEFAULT   12 sendmmsg@@GLIBC_2.14
  1100: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  ABS GLIBC_2.14
  1107: 0000000000089320    60 IFUNC   GLOBAL DEFAULT   12 memcpy@@GLIBC_2.14
  1310: 00000000000dc5a0    37 FUNC    GLOBAL DEFAULT   12 syncfs@@GLIBC_2.14
  5780: 0000000000089320    60 IFUNC   GLOBAL DEFAULT   12 memcpy@@GLIBC_2.14
  7421: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  ABS GLIBC_2.14

$ readelf -s /lib/libc.so.6 | grep GLIBC_2\.13
   501: 00000000000e2890    40 FUNC    GLOBAL DEFAULT   12 prlimit@@GLIBC_2.13
   556: 00000000000e30c0    37 FUNC    GLOBAL DEFAULT   12 fanotify_init@@GLIBC_2.13
   701: 00000000000e5180    92 FUNC    GLOBAL DEFAULT   12 __fentry__@@GLIBC_2.13
  1098: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  ABS GLIBC_2.13
  1233: 00000000000e2890    40 FUNC    WEAK   DEFAULT   12 prlimit64@@GLIBC_2.13
  1574: 00000000000e2930    40 FUNC    GLOBAL DEFAULT   12 fanotify_mark@@GLIBC_2.13
  7486: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  ABS GLIBC_2.13

Malvineous · 2012-02-26 01:53:42

Thanks for the quick reply! patchelf seems to have done the trick, much appreciated!

Yes I have already encountered the glibc issue, but luckily in this case it was only memcpy() that was affected and I could add an __asm__(".symver memcpy,memcpy@GLIBC_2.2.5"); to get around it.

Out of curiosity, is there any reason why Arch puts ld-linux-x86-64.so.2 in /lib rather than /lib64?

falconindy · 2012-02-26 03:08:44

Historically, we were a pure 64-bit distro (multilib is a more recent thing), so the distinction of /lib v. /lib64 didn't make sense for us.

Arch Linux

#1 2012-02-26 01:03:06

Linking to library using alternate path (/lib64 instead of /lib)

#2 2012-02-26 01:34:02

Re: Linking to library using alternate path (/lib64 instead of /lib)

#3 2012-02-26 01:53:42

Re: Linking to library using alternate path (/lib64 instead of /lib)

#4 2012-02-26 03:08:44

Re: Linking to library using alternate path (/lib64 instead of /lib)

Board footer