Re: [OE-core] Why does Openssl 1.0.2n use libcrypto.so.1.0.2 and not libcrypto.so.1.0.0?
On Wed, Aug 1, 2018 at 1:35 PM, Ryan Pabis (pabisr) via Openembedded-core 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" wrote: > > 2018-08-01 20:20 GMT+02:00 Ryan Pabis (pabisr) via Openembedded-core > : > > 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@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Why does Openssl 1.0.2n use libcrypto.so.1.0.2 and not libcrypto.so.1.0.0?
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. Ryan On 8/1/18, 3:47 PM, "Alexander Kanavin" wrote: 2018-08-01 20:20 GMT+02:00 Ryan Pabis (pabisr) via Openembedded-core : > 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@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Why does Openssl 1.0.2n use libcrypto.so.1.0.2 and not libcrypto.so.1.0.0?
2018-08-01 20:20 GMT+02:00 Ryan Pabis (pabisr) via Openembedded-core : > 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@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
