[OE-core] [RFC PATCH 1/6] openssl: rename openssl 1.0.x to openssl10 and make openssl 1.1.x the default version

Andre McCurdy armccurdy at gmail.com
Mon Sep 10 17:54:26 UTC 2018


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

Any further comments?

How are the meta-oe world builds looking now after the recent fixes?
Are there still issues?



More information about the Openembedded-core mailing list