Re: [docs] [PATCH 1/4] openssl-native.bbclass: add bbclass

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2022-10-04 at 14:38 +0300, Mikko Rapeli wrote:
> On Tue, Oct 04, 2022 at 12:09:18PM +0100, Richard Purdie wrote:
> 
> > I noticed there that the patches have thrown some compiler warnings:
> > 
> > crypto/conf/conf_mod.c:667:20: error: passing 'const char *(int)' to parameter of type 'const void *' converts between void pointer and function pointer [-Werror,-Wpedantic]
> >         if (dladdr(OpenSSL_version, &info)) {
> > crypto/conf/conf_mod.c: In function 'CONF_get1_default_config_file':
> > crypto/conf/conf_mod.c:667:20: error: ISO C forbids passing argument 1 of 'dladdr' between function pointer and 'void *' [-Werror=pedantic]
> >   667 |         if (dladdr(OpenSSL_version, &info)) {
> >       |                    ^~~~~~~~~~~~~~~
> > In file included from /usr/aarch64-linux-gnu/include/link.h:25,
> >                  from crypto/conf/conf_mod.c:34:
> > /usr/aarch64-linux-gnu/include/dlfcn.h:98:32: note: expected 'const void *' but argument is of type 'const char * (*)(int)'
> >    98 | extern int dladdr (const void *__address, Dl_info *__info)
> > 
> > 
> > It may be worth fixing those just in case they consider the patch.
> 
> Yes, but the general design of using dladdr(OpenSSL_version,...) did not
> get any positive comments in the bug report so I think this is wasted
> effort.

There isn't any feedback there saying dladdr is rejected, just that
they're not sure about the general use case. Getting changes accepted
by upstreams does usually require a bit of work so I'd not quite give
up yet! I can understand it from the maintainers side too, if you're
being asked to accept and maintain something, you do need there to be a
compelling reason for it.

> > I'm wondering whether we should just carry those patches? They don't
> > look so invasive and it would save complicating things elsewhere in our
> > codebase...
> 
> I don't think so. For every variable the patch is annoyingly different
> and there are merge/rebase conflicts with newer upstream releases
> already.

I didn't look in detail but at least the injected code blocks do look
relatively self contained which does make maintenance easier. The fact
they're had rebase conflicts already is sad/worrying though :(.

> I think pyton3native.bbclass sets the example. Variables need to be set
> for openssl to work correctly after relocation to paths not known at
> compile time. Same applies to any code which needs to dlopen() something
> or which has custom locations for modules, data or configuration files.

I'm not sure I'd hold python3native as a good example. It was what we
needed to do to get things to work and was the least worst thing :/.
Limitations to a single scripting language are much easier than a
general elf shared library.

Cheers,

Richard