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

[ Post a follow-up to this message ]

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.

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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.

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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 ;)

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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.

[ Post a follow-up to this message ]

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_m
ap.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.

[ Post a follow-up to this message ]