Richard L. Hamilton wrote:
>> 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)
Motif is also the classic example of why this is a bad idea,
from bad experiences with Netscape plugins that linked to a
different version of the Motif library than the Netscape binary,
and resulted in calls to mismatched functions.
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
