On Sun, Aug 18, 2002 at 01:03:38PM +0100, Richard Kettlewell wrote: > Panu Kalliokoski <[EMAIL PROTECTED]> 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
