Re: How does versioning work (was: Bug mixing old sem_wait and new pthread_cond_broadcast)

[Andreas Schwab]

Erland Lewin <address@hidden> writes:

|> I wrote:
|> > 
|> > |> Hello,
|> > |>
|> > |> I think there is a bug in linuxthreads, when the same thread uses
|> > |> pthread calls from both the old calls and new calls (for instance, when
|> > |> one library was made with an older glibc).
|>  
|> Andreas Schwab replied:
|> > You can't do that.  If you compile an application you must make sure all
|> > dependent libraries were compiled against the same version of glibc.  We
|> > only guarantee run time compatibility, but not link time compatibility.
|> 
|> Thanks for the clarification. Perhaps this should be pointed out in the
|> documentation (or did I miss it?).
|>   Wow. So that means, for instance, that I have to recompile X-windows
|> and all dependent libraries on my system if I want to program graphical
|> applications? That really makes upgrading glibc an enormous task. 

Yes, this is pointed out in the announcements.  On the other hand, the
situation isn't as bad, most of the time it just works anyway.  But again,
we cannot guarantee it.

|> But ok. I'm now trying to recompile all relevant libraries on my system,
|> but I find it difficult to understand how the versioning works.
|>   For example, I tried to recompile a new version of glib (from gtk)
|> from scratch.
|>   However, when I do (on the newly compiled libglib):
|> 
|> > ldd -v /usr/lib/libglib-1.2.so.0.0.9
|>      libc.so.6 => /lib/libc.so.6 (0x40033000)
|>      /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaaa000)
|> 
|>      Version information:
|>      /usr/lib/libglib-1.2.so.0.0.9:
|>              libc.so.6 (GLIBC_2.1.2) => /lib/libc.so.6
|>              libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
|>      /lib/libc.so.6:
|>              ld-linux.so.2 (GLIBC_2.1.1) => /lib/ld-linux.so.2
|>              ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2
|>              ld-linux.so.2 (GLIBC_2.2) => /lib/ld-linux.so.2
|>              ld-linux.so.2 (GLIBC_2.0) => /lib/ld-linux.so.2
|> 
|> I was expecting to see libc.so.6 (GLIBC_2.2) under the version
|> information for libglib-1.2.so.0.0.9. How should this look?

If the library does not use any symbol with version GLIBC_2.2 then it does
not depend on it.

|>   Is the library not linked against the latest GLIBC?

Yes, it is.  It just uses only features present in glibc 2.1.2 or earlier.

|>   Why are two versions of libc.so.6 listed under libglib-1.2.so.0.0.9? 

There are two _version symbols_ listed, both belonging to the same
library.

|>   How does the system determine which versions are required for a given
|> library?

It's encoded in the object image.  Use `objdump -p' to get a listing.

|>   Can I get the linker to warn if inconsistent glibc versions are used
|> in a binary/shared library?

The runtime linker will refuse to run the binary if it or its dependent
libraries require any undefined version symbols.

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
address@hidden
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5