|
Home > Archive > Unix Programming > October 2004 > how to determine glibc version programmatically?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
how to determine glibc version programmatically?
|
|
| Heny Townsend 2004-10-17, 5:50 pm |
| In porting my app to Linux I've run into an issue that's less of a
concern on other platforms. It requires a certain level of libc (aka
glibc on Linux and other GNU platforms) so I want the program to be able
to check the current version and give a warning if it's too low. I know
that you can execute the shared object on Linux and it will print the
version (along with a few paragraphs of other text), but what I'm
looking for is a documented API I can use in-process that returns a pure
string e.g. "2.3.2" which I can compare against. Anyone know of such a
thing?
--
Thanks,
Henry Townsend
| |
| Paul Pluzhnikov 2004-10-17, 5:50 pm |
| Heny Townsend <henry.townsend@not.here> writes:
> but what I'm looking for is a documented API I can use in-process that
> returns a pure string e.g. "2.3.2" which I can compare against. Anyone
Recent versions of glibc provide 'confstr(_CS_GNU_LIBC_VERSION, ...)'
which returns e.g. "glibc 2.3.2"
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
| Heny Townsend 2004-10-17, 8:50 pm |
| Paul Pluzhnikov wrote:
> Recent versions of glibc provide 'confstr(_CS_GNU_LIBC_VERSION, ...)'
> which returns e.g. "glibc 2.3.2"
Thanks, that looks absolutely perfect except, unfortunately, that
"recent versions" apparently means "really recent versions". AFAICT the
current release of glibc is 2.3.2 and, interestingly, I have two systems
(Debian 3.0r2 and Slackware 10.0) which both claim to use 2.3.2; one of
them implements _CS_GNU_LIBC_VERSION and the other doesn't. So I guess
it's a matter of patch levels to the present, the net result being that
any glibc which returns a string at all is by definition new enough. But
c'est la vie. Someday it'll be a useful feature.
--
Henry Townsend
| |
| Heny Townsend 2004-10-17, 8:50 pm |
| Heny Townsend wrote:
AFAICT the current release of glibc is 2.3.2 ...
Actually, I had that wrong. Current source release is 2.3.3.
--
Henry Townsend
| |
| Nils O. Selåsdal 2004-10-18, 7:50 am |
| Heny Townsend wrote:
> Paul Pluzhnikov wrote:
>
>
>
> Thanks, that looks absolutely perfect except, unfortunately, that
> "recent versions" apparently means "really recent versions". AFAICT the
> current release of glibc is 2.3.2 and, interestingly, I have two systems
> (Debian 3.0r2 and Slackware 10.0) which both claim to use 2.3.2; one of
> them implements _CS_GNU_LIBC_VERSION and the other doesn't. So I guess
> it's a matter of patch levels to the present, the net result being that
> any glibc which returns a string at all is by definition new enough. But
> c'est la vie. Someday it'll be a useful feature.
Are you sure you need to get the actual release ?
glibc should be backwards compatible a long way, but you need
to compile on a system with an old glibc, or use e.g. the LSB compiler
wrapper.
Else you might link to some versioned symbol, and your program
won't start on older glibc systems, so you won't even have a chance
to check it.
| |
| Heny Townsend 2004-10-18, 5:53 pm |
| Nils O. Selåsdal wrote:
> Are you sure you need to get the actual release ?
> glibc should be backwards compatible a long way, but you need
> to compile on a system with an old glibc, or use e.g. the LSB compiler
> wrapper.
> Else you might link to some versioned symbol, and your program
> won't start on older glibc systems, so you won't even have a chance
> to check it.
True, but in my case there's a simple wrapper program which execs the
complex one that cares about libc versions. As they will be compiled
together, and thus against the same libc.so, the wrapper could easily[*]
compare libc versions before handing over control.
[*] If the feature was more mature, as noted previously.
--
Henry Townsend
| |
| Nils O. Selåsdal 2004-10-18, 8:48 pm |
| On Mon, 18 Oct 2004 14:54:11 +0000, Heny Townsend wrote:
> Nils O. Selåsdal wrote:
>
> True, but in my case there's a simple wrapper program which execs the
> complex one that cares about libc versions. As they will be compiled
> together, and thus against the same libc.so, the wrapper could easily[*]
> compare libc versions before handing over control.
Yes, as long as your first program doesn't link to any of the newer
version symbols of glibc, in that case it won't start either ;)
| |
| Heny Townsend 2004-10-18, 8:48 pm |
| Nils O. Selåsdal wrote:
> Yes, as long as your first program doesn't link to any of the newer
> version symbols of glibc, in that case it won't start either ;)
It simply sets some environment variables and execs the main program, so
as long as putenv() and execv() haven't gone anywhere I'm ok. In a more
general case the wrapper could be a shell, Perl, etc script thus taking
advantage of pre-linked, pre-existing binaries to do the check. But
we're a bit off topic now.
--
Henry Townsend
| |
| Nils O. Selåsdal 2004-10-18, 8:48 pm |
| On Mon, 18 Oct 2004 17:39:22 +0000, Heny Townsend wrote:
> Nils O. Selåsdal wrote:
>
> It simply sets some environment variables and execs the main program, so
> as long as putenv() and execv() haven't gone anywhere I'm ok. In a more
> general case the wrapper could be a shell, Perl, etc script thus taking
> advantage of pre-linked, pre-existing binaries to do the check. But
> we're a bit off topic now.
Probably. Seems you should make a script parsing the
output of /lib/libc.so.6 (you can run the sharde library
as it were normal command) and extract the version from there.
| |
| Paul Pluzhnikov 2004-10-18, 8:48 pm |
| Nils O. Selåsdal <NOS@Utel.no> writes:
> Seems you should make a script parsing the
> output of /lib/libc.so.6 (you can run the sharde library
> as it were normal command) and extract the version from there.
I actually do do that, and recently ran into 2 problems :-(
- Debian 3.1rc2 ships with no-exec permissions on /lib/libc.so.6
and /lib/tls/libc.so.6, they *can't* be executed
This is easy enough -- I just do '/lib/ld-linux.so.2 /lib/libc.so.6'
instead.
- After installing their kernel-2.6.8 package, executing either /lib
or /lib/tls/libc.so.6 results in:
Inconsistency detected by ld.so: rtld.c: 1259: dl_main:
Assertion `_rtld_local._dl_rtld_map.l_prev->l_next == _rtld_local._dl_rtld_map.l_next'
Usually this means mis-match between libc.so and ld-linux.so,
except in this case it doesn't: only the kernel was upgraded,
and all programs continue to work; you just can't ask libc.so.6
what version it is.
It is failures like this that make supporting Linux
pain-in-the^H^H^H^H fun :-(
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
| Heny Townsend 2004-10-19, 2:48 am |
| Paul Pluzhnikov wrote:
> Nils O. Selåsdal <NOS@Utel.no> writes:
>
>
>
>
> I actually do do that, and recently ran into 2 problems :-(
Maybe I'm missing something, but there's also the issue of the other
kind of shared-lib versioning. How can you be sure the thing to execute
will always be /lib/libc.so.6? Might there not be a /lib/libc.so.7 some
day? On other systems you can count on /lib/libc.so to be a symlink to
"the right place" but I just ran into a system (Debian 3.1 or Slackware
10, can't remember) where no such link exists.
--
Henry Townsend
| |
| Paul Pluzhnikov 2004-10-19, 2:48 am |
| Heny Townsend <henry.townsend@not.here> writes:
> Maybe I'm missing something, but there's also the issue of the other
> kind of shared-lib versioning. How can you be sure the thing to
> execute will always be /lib/libc.so.6?
You can't. [You can do 'ldd /bin/date' and find out though.]
However, since all (current) binaries require libc.so.6, any system
that ships with libc.so.7 will also have libc.so.6 installed on it
(at least for a while).
Also, the fact that you can now introduce new symbols into libc.so.6
while maintaining backwardly-compatible old symbols, means that there
is very little (if anythying) to be gained by switching to libc.so.7,
and so such switch is highly unlikley.
If I understand the situation correctly, per-symbol versioning
essentially removed all need for 'external versioning' with different
actual DSOs (libc.so.4.1, libc.so.4.2, etc.), at least for stable
libraries (like libc).
Linux has survived from glibc-2.0 through 2.3.2 with libc.so.6;
Solaris 6 through 9 with libc.so.1
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
| James Antill 2004-10-19, 2:48 am |
| On Mon, 18 Oct 2004 16:41:26 -0700, Paul Pluzhnikov wrote:
> Nils O. Selåsdal <NOS@Utel.no> writes:
>
>
> I actually do do that, and recently ran into 2 problems :-(
In all this I fail to see why you can't just link with the lowest version
of libc that you've tested against and leave the rest to ABI compatibility.
Trying to do your own version of ABI compatibility is almost guaranteed
to stop working at some point. Esp. as you seem completely unaware of
symbol versioning, or what that means to your ABI.
> - Debian 3.1rc2 ships with no-exec permissions on /lib/libc.so.6
> and /lib/tls/libc.so.6, they *can't* be executed
Don't run beta software.
> This is easy enough -- I just do '/lib/ld-linux.so.2 /lib/libc.so.6'
> instead.
But will obviously fail if libc.so.6 ever needs a new ld-linux.
> - After installing their kernel-2.6.8 package, executing either /lib
> or /lib/tls/libc.so.6 results in:
>
> Inconsistency detected by ld.so: rtld.c: 1259: dl_main:
> Assertion `_rtld_local._dl_rtld_map.l_prev->l_next == _rtld_local._dl_rtld_map.l_next'
>
> Usually this means mis-match between libc.so and ld-linux.so,
> except in this case it doesn't: only the kernel was upgraded,
> and all programs continue to work; you just can't ask libc.so.6
> what version it is.
>
> It is failures like this that make supporting Linux
> pain-in-the^H^H^H^H fun :-(
*shrug* ... I have little sympathy for people who try to be clever and
complain when everything breaks.
--
James Antill -- james@and.org
Need an efficient and powerful string library for C?
http://www.and.org/vstr/
| |
| Paul Pluzhnikov 2004-10-19, 2:48 am |
| James Antill <james-netnews@and.org> writes:
> In all this I fail to see why you can't just link with the lowest version
> of libc that you've tested against and leave the rest to ABI compatibility.
I do. Unfortunately ABI compatibility is not good enough for me.
I have to work around various issues in glibc, and the way I work
around them differs between versions.
> Esp. as you seem completely unaware of
> symbol versioning, or what that means to your ABI.
I well aware of symbol versioning, thank you very much.
>
> Don't run beta software.
I don't. My users do :-(
>
> But will obviously fail if libc.so.6 ever needs a new ld-linux.
If libc.so.6 needs newer ld-linux, the system is unbootable anyway.
> *shrug* ... I have little sympathy for people who try to be clever and
> complain when everything breaks.
Shrug. You assume too much, me thinks.
Binary compatibility on Linux is fun for non-trivial applications,
especially if the user is expected to link with your binaries on
an arbitrary system he has assembled.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
| Norman Black 2004-10-19, 5:51 pm |
| >> I actually do do that, and recently ran into 2 problems :-(
>
> In all this I fail to see why you can't just link with the lowest version
> of libc that you've tested against and leave the rest to ABI
> compatibility.
I have been doing this for years. Quite simple and it works.
Norman
| |
| James Antill 2004-10-19, 5:51 pm |
| On Mon, 18 Oct 2004 23:44:46 -0700, Paul Pluzhnikov wrote:
> James Antill <james-netnews@and.org> writes:
>
>
> I do. Unfortunately ABI compatibility is not good enough for me.
> I have to work around various issues in glibc, and the way I work
> around them differs between versions.
What issues, bugs in different versions? If you can't move these to
runtime checks, and you must support the older broken versions ... then
you probably want to ship multiple versions each linked with the libc it
has the workarounds for. Or link with a local copy of libc, that you know
won't change.
>
> If libc.so.6 needs newer ld-linux, the system is unbootable anyway.
No, the update to the newer libc would provide the newer ld-linux.
True, I'm not expecting this to happen. But the point is that a _lot_ of
things _could_ change, another example is with a move to libc.so.7 the
..so.6 could be moved out of /lib with special knowledge of what to do in
ld.so.
The ABI is a contract between the app. and the libc authors, you can
assume that this contract won't be broken ... and more importantly lots of
other people rely on this contract. But the output of /lib/libc.so.6 it's
location or ld-linux etc. etc. isn't such a contract, and it's likely that
if any of those things change your app. will be the only thing to break.
>
> Shrug. You assume too much, me thinks.
>
> Binary compatibility on Linux is fun for non-trivial applications,
What you want isn't binary compatibility, lots of non-trivial
applications manage to have binary compatibility. You are trying to be
clever, and assuming compatibility where there is none. It will go wrong.
You are not helping yourself, or your users, by pretending otherwise.
> especially if the user is expected to link with your binaries on an
> arbitrary system he has assembled.
Yes, you can have "arbitrary" linux systems ... but you aren't required
to support them. For instance it's _possible_ for your users to assemble
a linux system that doesn't support ELF ... are you going to support that
too?
I'm assuming by link, you mean ld.so ... not ld. Which isn't what people
normally mean by link, but is the only thing that makes sense.
--
James Antill -- james@and.org
Need an efficient and powerful string library for C?
http://www.and.org/vstr/
|
|
|
|
|