Re: library names
Cristian Gafton wrote:
>
> On Fri, 26 Mar 1999, Burchard Steinbild wrote:
>
> > In a discussion we had the following question:
> >
> > > What will the naming convention be for /usr/lib/*std*
> > > In other words these:
> > > /usr/lib/libstdc++.so.2.9
> > > /usr/lib/libstdc++.so.2.9.0
> > > With this naming convention you can't tell if the lib was created on
> > > a libc5, glibc2.0, or glibc2.1 machine...
> >
> > this is not fully correct. At least it's no problem to decide if a lib
> > was build with libc5 or glibc.
>
> Yes, there are problems for applications that were compiled with the
> broken RPATH set (don't ask why people would do this, but they are doing
> it). Also, a lot of the versions that float around for
> libstdc++ were not linked against the C library (using -lc) and those libs
> will be "good to go" for any program that requires it, regardless of
> libc5/glibc issues.
>
> > I'm not sure, but would it also be
> > possible, to change ldso that way, that it can make a difference between
> > glibc2.0 and glibc2.1 libraries (maybe with the assumption "no versioning"
> > -> "2.0").
>
> The problem with this is that a potential mix of glibc 2.0 and glibc 2.1
> libraries is fatal. For example if you decide to load glibc 2.0 for a
> program based on the lack of versioning, that program might require
> another library for which you don't have a glibc 2.0 version, so the
> loader will have to proceed and load the glibc 2.1 one, which in turn will
> load glibc 2.1, so you will end up with glibc 2.0 and glibc 2.1 loaded at
> the same time for a program.
>
> > > Redhat's next release (glibc 2.1 base) has a new naming convention which
> > > incorporates the glibc version into the name...ie:
> > >
> > > /usr/lib/libstdc++-2-libc6.1-1-2.9.0.a
> > > /usr/lib/libstdc++-libc6.1-1.a.2 -> libstdc++-2-libc6.1-1-2.9.0.a
> >
> > On our meeting we agreed not to worry too much about backward
> > compatibility due to glibc versions. But imho this has to be covered
> > in LSB anyway.
>
> The general idea is that we are using in our egcs compiler the Linux patch
> put together by H. J. Lu. That includes this "hack" with which I happen to
> agree because of the multiple failure scenarios.
>
> > Please Christian, give me another chance and explain me, why this ugly
> > names in your opinion are a MUST. Thanks.
>
> I don;t think that the names matter that much - it's just a soname and the
> system takes care of it, ugly or not. The problem we are trying to solve
> here is caused by the fact that libstdc++ is a very special library and
> libstdc++ compiled against glibc 2.0 is not compatible with the one
> compiled against glibc 2.1. So if a vendor compiles an app on glibc 2.0
> and it is using that system's libstdc++ the respective app will not run on
> a glibc 2.1 system if the glibc 2.1 system does not change the soname of
> the libstdc++ library and provides the old one as a backward
> compatibility.
In short, why ? An example for the uninitiated ... wasn't the .x.y
extension of sonames supposed to help ?
More questions:
- how do I produce a .so which exhibits the problem ?
- how do I produce a .so which avoids the problem (while still using
glibc) ?
- what makes libdstdc++ special ?
> And this is only a part of the problem, you also have gcc/egcs issues
> (both ship libstdc++.so.9) and guess what - they are incompatible.
>
> So the issues imho is not if changing the name so we will stop using
> libstdc++.so.9 no matter of the compiler/library combination - we can
> argue about the form of the new soname, making the names less "ugly", etc.
>
> But IMHO is better to tell the vendors that one libstdc++ might not be
> compatible with another one on another system than to keep their hopes
> high and then make them spend time debugging stuff to discover what we
> already know about the incompatibilities.
Are details about glibc, libdstdc++ and incompatibilities thereof
available somewhere on the Internet, possibly with examples ?
> And the patch we use by no means is RH specific or anything - it is a
> patch put out by H. J. Lu, and it just so happens that I trust that patch
> because so far it is the only solution that I know of that will make egcs
> give reproducible results.
>
> Best wishes,
>
> Cristian
> --
> ----------------------------------------------------------------------
> Cristian Gafton -- gafton@redhat.com -- Red Hat Software, Inc.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> UNIX is user friendly. It's just selective about who its friends are.
>
> --
> To UNSUBSCRIBE, email to lsb-discuss-request@lists.linuxbase.org
> with subject of "unsubscribe". Trouble? Email listmaster@lists.linuxbase.org
Davide Bolcioni
--
#include <disclaimer.h> // Standard disclaimer applies
Reply to: