[EMAIL PROTECTED] wrote: > Please note that libssl0.9.7 and libssl0.9.8 have a different > SONAME. There can only be a problem when a program (indirectly) > links to both of them. In that case, there isn't even an option > not to install both of them. > > If a program is linked to both of them, and it was not linked to > a lib with versioned symbols, there really isn't much you can > tell about which symbols it's going to pick. Right. Thanks for being clearer than me.
Consider the fate of a binary built against libssl0.9.8 with unversioned symbols, once libssl0.9.8 with versioned symbols is installed. Suppose also that libssl0.9.7 -- with unversioned symbols -- is indirectly linked in (very likely in complicated situations like KDE, and because libssl may be dlopened). The dynamic linker will resolve the unversioned symbols from the binary -- supposed to be, at least in some cases, libssl0.9.8 symbols -- to the unversioned symbols it finds, namely, the ones in libssl0.9.7. This is bad if the ABI has actually changed between 0.9.7 and 0.9.8, as it will lead to tricky-to-track-down bugs at runtime. It would be best, therefore, if nothing were built against libssl0.9.8 until the libssl0.9.8 with versioned symbols is available (after which everything will be hunky-dory). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
