> On 5/10/07, Laszlo (Laca) Peter <laca at sun.com> wrote: > > > > The real trouble is what happens when multiple > version of the same > > lib meet in an executable. It happens sometimes > and there's no > > easy way to avoid or fix it. Actual examples are > the acroread crash > > (caused by a libz collision) and currently various > GNOME apps > > crash due to a clash between libexpat in Python and > in /usr/sfw. > > The lower level the library, the higher the > probability that it'll > > cause troubles. Tck/Tk is probably okay in this > regard, but where > > do you draw the line? > > I don't know. But I think something's going to have > to be worked > out, and I keep bringing it up in the hope that > someone way > smarter than myself will work out a way to cleanly > support > multiple versions.
In the more disciplined internal environment, wouldn't that be handled by incrementing the shared library version number for each incompatible ABI change, along with perhaps some #ifdefs in the header if one wished to continue to support compiling for both versions (which is separate from simply keeping the old libs around)? (I'm thinking of Motif 1.4 vs 2.x as an example) I don't see how that could be done without altering the build procedures at least a little. Sun was a big player in the development of the shared linker/library approach that's very similar between Solaris and Linux. You would think they could find a way to communicate their experience with how to manage library versions, define ABI compatibility, proper use of -R linker option and avoidance of LD_LIBRARY_PATH, etc. such that they could get the idea across to more open source application developers, without sounding arrogant or too much pooh-poohing the philosophy of open source primacy over binary compatibility, but rather pointing out how much it would simplify deployment, relieve dependency problems, allow the developers to get more and cleaner feedback, etc. Having widespread acceptance of conventions for how to manage these problems seems to me a more discipline-based solution than any particular bit of technical wizardry (such as extended linker configuration allowing particular executable pathnames to be bound to particular library pathnames, regardless of embedded library search path, along with a program that will capture the linkage state of any working executable and add its configuration to that special case list; none of which AFAIK exists now, BTW). This message posted from opensolaris.org
