<div dir="ltr"><div dir="ltr"><div dir="ltr"><a href="https://wiki.debian.org/OpenSSL-1.1">https://wiki.debian.org/OpenSSL-1.1</a> says it will cause runtime bugs like segmentation faults or just misbehaving applications.<br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 5, 2018 at 5:45 PM Andre McCurdy <<a href="mailto:armccurdy@gmail.com">armccurdy@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Sep 5, 2018 at 8:15 AM, Khem Raj <<a href="mailto:raj.khem@gmail.com" target="_blank">raj.khem@gmail.com</a>> wrote:<br>
> On Wed, Sep 5, 2018 at 7:45 AM Richard Purdie<br>
> <<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>> wrote:<br>
>><br>
>> On Wed, 2018-09-05 at 10:53 +0200, Martin Jansa wrote:<br>
>> > But patching the components to use libssl10 might actually work<br>
>> > (unlike<br>
>> > just changing DEPENDS to openssl10).<br>
>> ><br>
>> > It's not only conflicting in build-time in RSS, but it will conflict<br>
>> > on target as well. You either need to migrate all components included<br>
>> > in image to 1.1 or all stay on 1.0.<br>
>><br>
>> That isn't quite the case. For OE-Core we have images using both 1.0<br>
>> (openssh) and 1.1 installed together. Its true there are some issues if<br>
>> you try and parallel install both the -dev packages but normal target<br>
>> images are working.<br>
>><br>
>> We could probably "fix" the -dev images to an extent by making 1.1<br>
>> replace 1.0 dev pieces.<br>
>><br>
>> The build time sysroot problem is harder unfortunately, I've ideas<br>
>> about things we might be able to do but haven't experimented as yet.<br>
>><br>
><br>
> If runtime conflicts are clear<br>
<br>
I don't think the runtime issues are clear.<br>
<br>
Being able to install both versions of openssl on the target and have<br>
them be used by different applications is one case (already solved by<br>
different sonames).<br>
<br>
But the builds that are failing in meta-oe are a different case - a<br>
single application is indirectly linked against both versions of<br>
openssl. Loading two versions of openssl into the same address space<br>
at runtime hasn't been solved... and may not be realistically solvable<br>
- e.g. what happens if code in an app compiled against openssl 1.1<br>
tries to share an openssl data type with code in a library compiled<br>
against openssl 1.0?<br>
<br>
> I think we can install the headers into /usr/include/openssl10/<br>
> and dev libs into /usr/lib/openssl10<br>
> and provide a openssl10.pc file to we can use pkgconfig in packages<br>
-- <br>
_______________________________________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
</blockquote></div>