On Sat, Aug 17, 2002 at 01:38:42PM -0500, Steve Langasek wrote: > On Sat, Aug 17, 2002 at 08:00:02PM +0300, Panu Kalliokoski wrote: > > I'll throw in my views on the subject: > > > (1) If I understand correctly, SONAMEs are not meant to provide any > > other metadata than a reference to the *library's* ABI. Using SONAMEs for > > anything else, like which compiler the library was built with, will most > > probably result in very broken behavior, because the upstream authors > > have little way to ensure that their library with SONAME n will always > > be built with compiler x but their library with SONAME m will always be > > built with compiler y. > > But in a very real sense, the compiler used *IS* part of the library's > ABI; if you recompile a C++ library with gcc 3.2 instead of gcc 2.95, > the name of pratically *every* *single* *symbol* will change. That > rather soundly eliminates any question of compatible ABIs between the two > libraries.
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?), changing SONAMES will be a real pain. Another possibility that didn't occur to me was having gcc somehow set the SONAME itself - but this seems to me somehow very ugly. > Of course, you may still be right that it's better to code this > information somewhere other than in the soname itself. The problem is > that currently, the transition plan doesn't allow for it to be stored > anywhere other than in the package system. I, at least, hope that the ...c versions can coëxist with the old versions. (i.e. not the packages, nor the libraries, should conflict in any way.) Panu
