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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171389):
https://lists.openembedded.org/g/openembedded-core/message/171389
Mute This Topic: https://lists.openembedded.org/mt/94110827/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
