[OE-core] Why does Openssl 1.0.2n use libcrypto.so.1.0.2 and not libcrypto.so.1.0.0?

[Andre McCurdy]

On Wed, Aug 1, 2018 at 1:35 PM, Ryan Pabis (pabisr) via
Openembedded-core <openembedded-core at lists.openembedded.org> wrote:
> Alex,
>
> The library was precompiled by tail-f but I've also recompiled on Ubuntu 16.04 with openssl 1.0.2n.  In both cases the library crypto.so and libconfd.so refer to libcrypto.so.1.0.0.
>
> Having a pre-compiled library worked on krogoth and morty, but does not seem to work on rocko.

You can often find the answer to questions like this by looking at the
git history and reading the comments from the commit which made a
particular change. In this case see:

  http://git.openembedded.org/openembedded-core/commit/?id=1b430eef7131876bc735c22d66358379b0516821

ie the explanation given was that other distros are not consistent in
the soname they use and oe-core has chosen to follow Debian - which
apparently uses 1.0.2.

If you have a library which needs 1.0.0 then you can try to hack
around the mismatch by adding symlinks from libXXX.so.1.0.0 ->
libXXX.so.1.0.2 in the rootfs (and ignoring the file-rdeps QA test).

But as Alex mentions, be very careful about just copying binaries
created outside OE into an OE rootfs. By over-riding the soname you
are basically disabling sanity checks that prevent mismatches in
library APIs, so you could see crashes etc at runtime. The fact that
your preompiled library worked on krogoth and morty may just have been
luck.

If you have the source to (re)build under Ubuntu then why can't you
also build from an OE recipe? That would be the real solution.


> On 8/1/18, 3:47 PM, "Alexander Kanavin" <alex.kanavin at gmail.com> wrote:
>
>     2018-08-01 20:20 GMT+02:00 Ryan Pabis (pabisr) via Openembedded-core
>     <openembedded-core at lists.openembedded.org>:
>     > I have a library that uses libcrypto.so.1.0.0 from openssl 1.0.2n, which is
>     > the libcrypto.so version if you download the source code to ubuntu 16.04
>     > from openssl and compile.  However, Yocto Rocko uses the same openssl 1.0.2n
>     > version but it uses libcrypto.so.1.0.2 and sets the FILERDEPENDS_ to the
>     > same.  This causes a file_rdeps issue for me because it says
>     > libcrypto.so.1.0.0()(64bit) is not provided.
>     >
>     >
>     >
>     > I’ve tried adding, DEPENDS += “openssl” and RPDEPENDS_confd += “openssl”,
>     > with no luck.  The only way I can get it to compile is if I manually hack my
>     > library and change from libcrypto.so.1.0.0 to libcrypto.so.1.0.2 (even
>     > though it was really compiled with libcrypto.so.1.0.0 and that’s the
>     > libcrypto version of openssl 1.0.2n).
>     >
>     >
>     >
>     > Can someone please advise?
>
>     In which environment was the library built? You generally cannot take
>     something that was compiled outside of Yocto. Write a recipe that
>     builds the library from source code, or ask the provider of that
>     library to do that.
>
>     Alex
>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core