Re: [RFC] make preferred openssl version match for -native recipe

[Koen Kooi <k.kooi@student.utwente.nl>]

On 02-04-09 05:03, Mike (mwester) wrote:
> Mike (mwester) wrote:
>> I'd like to propose that we remove the "DEFAULT_PREFERENCE = "-1"" line
>> from openssl-native_0.9.8j.bb.
>>
>> This is causing a problem in select cases (for example, python-native
>> fails "import md5"), because we build and stage openssl 0.9.8j, but the
>> corresponding -native that gets built and staged is openssl 0.9.7g.
>>
>> The 0.9.8j version is currently selected as the PREFERRED_VERSION in the
>> preferred-om-2008-versions.inc file, as well as for SlugOS.  I've
>> successfully built it on both 32 and 64 bit hosts.
>>
>> Unless there are objections, I'll commit a fix in a couple of days.
>
> Fix committed. (To dev, not to the new stable branch.)
>
> WARNING!  The "correct" thing to do would probably be to bump up the PR
> on all recipes that might include, directly or indirectly, openssh libs
> -- thus forcing them all to link against the new version...
>
> However, that seemed to be an awful lot of packages, and given that at
> least some of the distros already have over-rides to select matching
> versions for openssl and openssl-native, this would seem to cause more
> problems than it would solve.
>
> So anticipate that your builds may fail if a new version of openssl is
> built; the failure mode would be the inability for the app to find the
> old version of the library in the staging area.

You mean like this: 
/OE/angstrom-dev/staging/x86_64-linux/usr/bin/edje_cc: error while 
loading shared libraries: libssl.so.0.9.7: cannot open shared object 
file: No such file or directory

Could you please do things properly and bump PR for the affected recipes?