Re: library names
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.
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.
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.
Reply to: