tags:

views:

145

answers:

1

Notice these two RedHat Linux system configuration settings:

$ getconf GNU_LIBC_VERSION
glibc 2.3.4

$ getconf GNU_LIBPTHREAD_VERSION
NPTL 2.3.4

I see they correspond to some of the TLS libraries:

/lib/tls/libc-2.3.4.so
/lib/tls/libm-2.3.4.so
/lib/tls/libpthread-2.3.4.so
/lib/tls/librt-2.3.4.so

I'd like to link against these libraries instead of the /usr/lib equivalents. I have a few questions:

  1. I've seen this on RedHat and Debian. Does it exist on all GNU Linux distributions?
  2. Is there any case where GNU_LIBC_VERSION differs from GNU_LIBPTHREAD_VERSION?
  3. Are those variables safe to use for identifying the shared libraries in /lib/tls? I'd like to automate this in a Makefile, rather than hard-coding a magic glibc/pthread version number.
+2  A: 

The NPTL project which first implemented pThreads on Linux was a separate project initially adding kernel support and providing its own library.

When it was stable enough it was merged into glibc. I would assume that those two versions are identical on all reasonably up-to-date installations.

On Ubuntu 8.10 the output is like this:

$ getconf GNU_LIBC_VERSION
glibc 2.8.90
$ getconf GNU_LIBPTHREAD_VERSION
NPTL 2.8.90
Joachim Sauer
Does your system have /lib/tls/libc-2.8.90.so?
Tom
No, but it's got /lib/tls/i686/cmov/libc-2.8.90.so.Shouldn't it be the linkers job to find the correct version/location of that library?
Joachim Sauer
It should be, but it sort-of isn't. The linker will fild /usr/lib/libc.so, so it will resolve only the symbols found there. But it will run against /lib/tls/..., so there are additional symbols available. I have to jump through hoops to link against /lib/tls.
Tom
Though, I would think that /lib/tls/i686/cmov/ on your machine, and /lib/tls on my machine, would be programmatically defined from some other part of the environment (since it gets referenced for runtime resolution). I just haven't figured that part out yet.
Tom