On Mon, 2011-02-07 at 09:16 -0800, Arjan van de Ven wrote: > On 2/7/2011 9:03 AM, Gabriel M. Beddingfield wrote: > > On Mon, 7 Feb 2011, Sergio Schvezov wrote: > > > >>> Suppose that your app needs 3rd party libs and you install > >>> them in the folder /opt/foo/lib. Before you start your app, > >>> you can manipulate the LD_LIBRARY_PATH to pull in your lib > >>> folder. > > [snip] > >> > >> So imagine the case of openssl, you provide it as it is not Meego Core, > >> it's linked to a specific version. Meego provides a different one, you > >> an't link to it in theory as it is not a core lib. In this example you > >> then bring in Qt to your application which does a dlopen on it's > >> openssl. This basically crashes your app. > > > > What a mess! I hadn't thought of that. > > > >> My point being, some libs just probably shouldn't be allowed even in an > >> LD_LIBRARY_PATH. > > > > I.e. "We refuse to supply openssl as part of MeeGo core, but you can't > > use openssl as your own private library because QtNetwork is covertly > > loading it with dlopen()." That's nuts. > > I'm pretty sure openssl is part of the actual compliance package list > (which is "core + dependencies", not just "core')
If you compile your app against libssl in Meego 1.1 it will link against libssl.so.8, when you go to Meego 1.1.90->1.2 your app won't load as libssl.so.10 is there. If you symlink it may work, but you can never know as that's why the version changed in the first place. Same applies for libcrypto. That being said, I think and take from the comliance document that API/ABI stability only apply to the libs marked as core. The compliance checker tool should take that into account.
_______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
