Re: GCC 3.2 transition
On Sun, Aug 18, 2002 at 01:03:38PM +0100, Richard Kettlewell wrote:
> Panu Kalliokoski <pkalliok@ling.helsinki.fi> writes:
> > You're right; I'm just more worried about the more practical point
> > that if a library, when being built, cannot know which SONAME it
> > should install itself under (it would involve checking the version
> > of compiler used, right?),
> I think you've answered your own question; it _can_ known which soname
> to use, and to discover it, it should check the version of the
> compiler.
I'm not sure whether you're actually proposing changing the SONAMEs so
that the library will compile itself with different SONAME depending on
the compiler, but let me say some more problems with using SONAME for
the transition (even if upstream could be convinced to do this, which in
practice most certainly is the biggest problem):
Let's say libfoo version 17.1.6 will be the first libfoo to compile
itself under libfoo.so.8 if gcc 2 is being used, libfoo.so.9 if gcc 3 is
being used. You're right, this seems sensible because the libraries do
have incompatible ABI's. Further releases will retain this separation.
But what will happen when the library's *own* ABI (the thing SONAMEs are
really meant for) changes? Will libfoo 18.0.1 install itself under
libfoo.so.10 if gcc 2 is being used, libfoo.so.11 if gcc 3? Or is
support for gcc 2 to be dropped from these releases? Why should it be a
library's business at all to provide information about what compiler the
user programs should use, and to dictate when they cannot use compiler X
anymore?
The basic problem here is that SONAMEs contain insufficient information,
which for example in the case of libc transition was too weak to express
which other libraries the library is linked against, and now is (and
should IMO not be made otherwise) too weak to tell which compiler was
used to compile the library. It would be very nice to have a
standardised way for a library to export all information that will be
necessary for the linker to find just the library that will not break
anything. But such a standard should be treated as a standard, maybe
an extension to ELF, and be subject to much discussion before being
taken in use. Then maybe, if debian is lucky, the other distros will
deem it worthwhile to be binary-compatible with the new standard.
In practice, this kind of situation (ABI's being dictated by factors
that are orthogonal to each other) hasn't occurred too much in practice
yet, and the "nice" workaround that will not make unnecessary conflicts
is to have different SONAME namespaces. One way to achieve this could be
gcc 3.2 automatically linking against a different dynamic linker.
(Basically, if the dynamic linker was written in C++ (which it isn't),
this would be the only option anyway.) Does gcc's upstream have any
views on this?
> (I believe it's also necessary to incorporate information about the
> sonames - i.e. ABIs - of libraries that this library depends on it,
> into its soname too.)
I think the information should be incorporated _somewhere_. But as I
said above, this should be a matter of common standardisation.
> Not changing sonames[1] when the ABI changes would also be incredibly
> painful; bits of software that people use and depend on would start
> crashing.
Well, it is sufficient that the linker gets the additional information
from somewhere. Of the two ways (hacking the linker to use different
versions depending on the ABI, or having two dynamic linkers) the latter
is IMO cleaner, but neither will break anything.
Panu
Reply to: