On Fri, 2007-05-11 at 10:43 -0400, Dennis Clarke wrote: > On 5/11/07, Laszlo (Laca) Peter <laca at sun.com> wrote: > > On Fri, 2007-05-11 at 00:04 +0100, Peter Tribble 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. > > > > Let me Cc tools-linking, maybe there is some linker magic that > > can help. AFAIR direct binding can help in some cases. > > We certainly can't solve this problem with just file system > > namespacing. > > This is one of those things that the Blastwave project needs to deal > with also. Then again we don't put anything into /usr and we do try to > keep older lib revisions around when needed. For example let's look at > the libs that come with the OpenSSL package : > > # ls -1 /opt/csw/lib/libcrypto.so.0.9.* /opt/csw/lib/libssl.so.0* > /opt/csw/lib/sparcv8plus/libcrypto.so.* > /opt/csw/lib/sparcv9/libcrypto.so.* /opt/csw/lib/sparcv9/libssl.so.0* > /opt/csw/lib/libcrypto.so.0.9.6 > /opt/csw/lib/libcrypto.so.0.9.6.20060915191807.23077 > /opt/csw/lib/libcrypto.so.0.9.6.20061008142346.10983 > /opt/csw/lib/libcrypto.so.0.9.7 > /opt/csw/lib/libcrypto.so.0.9.7.20060915191807.23077 > /opt/csw/lib/libcrypto.so.0.9.7.20061008142346.10983 > /opt/csw/lib/libcrypto.so.0.9.8 > /opt/csw/lib/libcrypto.so.0.9.8.20060915191807.23077 > /opt/csw/lib/libcrypto.so.0.9.8.20061008142346.10983 > /opt/csw/lib/libssl.so.0.9.6 > /opt/csw/lib/libssl.so.0.9.6.20060915191807.23077 > /opt/csw/lib/libssl.so.0.9.6.20061008142346.10983 > /opt/csw/lib/libssl.so.0.9.7 > /opt/csw/lib/libssl.so.0.9.7.20060915191807.23077 > /opt/csw/lib/libssl.so.0.9.7.20061008142346.10983 > /opt/csw/lib/libssl.so.0.9.8 > /opt/csw/lib/libssl.so.0.9.8.20060915191807.23077 > /opt/csw/lib/libssl.so.0.9.8.20061008142346.10983 > /opt/csw/lib/sparcv8plus/libcrypto.so.0.9.7 > /opt/csw/lib/sparcv8plus/libcrypto.so.0.9.7.20060915191807.23077 > /opt/csw/lib/sparcv8plus/libcrypto.so.0.9.7.20061008142346.10983 > /opt/csw/lib/sparcv8plus/libcrypto.so.0.9.8 > /opt/csw/lib/sparcv8plus/libcrypto.so.0.9.8.20060915191807.23077 > /opt/csw/lib/sparcv8plus/libcrypto.so.0.9.8.20061008142346.10983 > /opt/csw/lib/sparcv9/libcrypto.so.0 > /opt/csw/lib/sparcv9/libcrypto.so.0.9.7 > /opt/csw/lib/sparcv9/libcrypto.so.0.9.7.20060915191807.23077 > /opt/csw/lib/sparcv9/libcrypto.so.0.9.7.20061008142346.10983 > /opt/csw/lib/sparcv9/libcrypto.so.0.9.8 > /opt/csw/lib/sparcv9/libcrypto.so.0.9.8.20060915191807.23077 > /opt/csw/lib/sparcv9/libcrypto.so.0.9.8.20061008142346.10983 > /opt/csw/lib/sparcv9/libssl.so.0 > /opt/csw/lib/sparcv9/libssl.so.0.9.7 > /opt/csw/lib/sparcv9/libssl.so.0.9.7.20060915191807.23077 > /opt/csw/lib/sparcv9/libssl.so.0.9.7.20061008142346.10983 > /opt/csw/lib/sparcv9/libssl.so.0.9.8 > /opt/csw/lib/sparcv9/libssl.so.0.9.8.20060915191807.23077 > /opt/csw/lib/sparcv9/libssl.so.0.9.8.20061008142346.10983 > # > > This allows any previous package to have linkage with previous libs > while also providing present up-to-date packages. The trick is to > migrate packages forwards continually. > > Not to mention testing testing testing ... which as of this morning I > think that a few of us here have poured fifty or sixty hours into > GNOME and XFCE thus far.
Right. So this is the "easy part". libssl seems particularly troublesome, as it's very low level and many libs in Solaris already depend on the version shipped in Solaris. To avoid crashes in csw, you can (and you have to) avoid using any libs from Solaris that link against /usr/sfw/lib/libssl.so.*. But what if there are 2 versions of the same lib _in_ Solaris? The equivalent solution is making everything link to only one of them. So keeping the other one around will keep some 3rd party sw going and will cause others to crash. That's what we need a solution for. Am I making sense or do I need more coffee? Laca PS: %s/Solaris/any OpenSolaris based distribution/g
