Panu A Kalliokoski <[EMAIL PROTECTED]> writes: > Richard Kettlewell wrote:
>> 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, Yes, that sounds exactly like what I'm saying. > 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? That seems a reasonable approach for as long as both ABIs need to be supported. What's the problem with that? > 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? This happens already; for instance, the kernel has a preferred gcc versions required to build it, and this changes from time to time. With C++ at the moment we'll probably see more of that rather than less: the older compilers don't even implement the full language correctly. So I suspect the fear of having to support multiple compiler ABIs for many years hence is unfounded in practice. > 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. Another variant that I think would work but haven't tried, would be to have the information encoded in the name part of the soname rather than the number, thus somewhat breaking the relationship between the name that you link against at compile time and the soname. I've never actually tried this but I believe it would work. But you can pack lots and lots of information into an integer. I think the choice of approach can be left to upstream, as long as they do _something_ to signal the ABI change. >> 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. I'm not yet convinced that the "hack the linker" approach actually works properly; it requires Debian to move one set of libraries (say, those with the older ABI) to a new path. It can and may do this for libraries in Debian packages, but cannot and must not for libraries installed into /usr/local. -- http://www.greenend.org.uk/rjk/
