2

When I'm compiling my elf, it is "best practice" to make it link against the oldest version of glibc I can, so it will work both on new and old versions of glibc.

i.e. if I use realpath, which in readelf output of glibc we can see has both a GLIBC_2.0 version and a GLIBC_2.3 version, I want to use the old version so my ELF would work on glibc 2.0/1/2.

But the GLIBC_2.3 version was probably developed and upgraded since it was published, and I guess GLIBC_2.0 version hasn't changed since glibc 2.3 has been published. So I guess I want my elf to use GLIBC_2.3 version when it is present, and when not, to fallback to the GLIBC_2.0 version.

Is is possible? Or what don't I understand?

Improve this question
2
  • Crossposted to S.O.
    – goldilocks
    Feb 22, 2015 at 21:00
  • Versioned symbols were only introduced with glibc 2.1. The best method would probably be to use no symbol versions at all (which means instead of linking memcpy@GLIBC_2.0 you'd link memcpy, ending up with the default - which seems to be the most recent by default).
    – 0xC0000022L
    May 4, 2017 at 13:34

1 Answer 1

Reset to default
0

I've never heard of any such practice, much less calling it a best practice. The closest thing I can think of is that if you look at ELF malware, it's often compiled against really old versions of the Linux kernel, and old versions of libc. I'm not sure that counts as a "best practice" however.

I don't think an explicit fall back is possible, given how Linux gets an ELF executable into memory. All the kernel does is map sections of the ELF file into memory, according to PT_LOAD Pheaders of the file. Linux also maps in the "interpreter", which is usually /lib/ld-linux.so.2 or /lib64/ld-linux-x86-64.so.2. That interpreter is part of libc, and it's responsible for doing any dynamic linking against libc.so or any other shared objects.

An ELF file gets linked against whatever shared objects are available, that's why I wrote that no explicit version choice is possible. It's all up to the ELF interpreter.

Improve this answer
1
  • 1
    For starters, yes it's possible but ugly. The the thread starter is compiling him-/herself, there are ways to redirect the linker to the "right" older symbol. And yes, for all the software that cannot link glibc statically for licensing reasons (read: proprietary software), this is indeed a best practice and has been for a long time. Usually it's done by having a really old distro version installed with toolchain and all, to become compatible with the glibc contained in that distro version (and newer). However, that's cumbersome. I guess that's why this question was asked.
    – 0xC0000022L
    May 4, 2017 at 13:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .