Guaranteed correctness after upgrading glibc (was: How does versioning work)

[Erland Lewin]

Thank you for your reply Andreas.

> |> I wrote:
> |> >
> |> > |> 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.
 
Andreas replied:
> Yes, this is pointed out in the announcements.  

Perhaps it should also be pointed out in the installation instructions
that for guaranteed correct behaviour, all shared libraries on the
system need to be recompiled after a glibc upgrade. As far as I can
tell, this might even be the case after even an upgrade from, say, 2.1.1
to 2.1.2, since there are new version symbols introduced for even minor
version upgrades.

If I understand things correctly, this is the case even for a user
(non-programmer) upgrading glibc. If a user upgrades glibc (say to
2.2.2), and then downloads a binary version of an application which was
compiled with 2.2.2 things will appear to work, but may yield mysterions
bugs if the application uses a shared library which was not recompiled
after the glibc upgrade.

In my opinion it is not reasonable that the whole system needs to be
reinstalled after a glibc upgrade for guaranteed correct behaviour.

FWIW I couldn't find the announcement. I looked at the glibc home page
(www.gnu.org/software/libc), in the glibc-2.2.2.tar.gz archive, and the
glibc-annouce archives at
http://sources.redhat.com/ml/libc-announce/2001/

> On the other hand, the
> situation isn't as bad, most of the time it just works anyway.  But again,
> we cannot guarantee it.

In order to avoid obscure and difficult to find bugs stemming from mixed
library versions (like the pthread-crash I originally pointed out; I
have 
another program with "dirent" problems), I want some way to guarantee
that shared libraries compiled with different glibc versions are not
mixed. "most of the time it just works anyway" is not enough, because it
might cause substantial work to track down mysterious bugs.

If I understand the current situation, it is not possible to see which
libraries need to be recompiled, in order to guarantee proper behaviour.
Is this true?
  It would be very desirable if a feature could be constructed such that
it is possible to see which glibc version a given library was compiled
with. If this feature could be used for run-time (dynamic link time?)
warnings if incompatible glibc versions are used, that would be even
better.

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

This doesn't solve the problem at hand.

  Best regards,

    Erland