* Re: [Buildroot] [PATCH 1/1] package/php: depend on libucontext for musl builds
2023-05-16 19:33 [Buildroot] [PATCH 1/1] package/php: depend on libucontext for musl builds Bernd Kuhls
@ 2023-08-06 16:03 ` Thomas Petazzoni via buildroot
0 siblings, 0 replies; 2+ messages in thread
From: Thomas Petazzoni via buildroot @ 2023-08-06 16:03 UTC (permalink / raw)
To: Bernd Kuhls; +Cc: buildroot
Hello Bernd,
On Tue, 16 May 2023 21:33:07 +0200
Bernd Kuhls <bernd.kuhls@t-online.de> wrote:
> diff --git a/package/php/Config.in b/package/php/Config.in
> index 69b4268c1d..18779ba1f9 100644
> --- a/package/php/Config.in
> +++ b/package/php/Config.in
> @@ -8,7 +8,9 @@ config BR2_PACKAGE_PHP_ARCH_SUPPORTS
> default y if BR2_powerpc || BR2_powerpc64 || BR2_powerpc64le
> default y if BR2_RISCV_64
> default y if BR2_s390x
> - default y if BR2_TOOLCHAIN_HAS_UCONTEXT
> + default y if \
> + BR2_TOOLCHAIN_HAS_UCONTEXT || \
> + BR2_PACKAGE_LIBUCONTEXT_ARCH_SUPPORTS
Thanks for looking into this.
I think this isn't the right solution, but it's not your fault: the
semantic of BR2_TOOLCHAIN_HAS_UCONTEXT today is fuzzy and vague, and
it's actually quite wrong how it's working.
If you look at your commit, you're basically saying that "some
toolchains define BR2_TOOLCHAIN_HAS_UCONTEXT, but in fact they don't
really provide ucontext support so we need to use an extra libucontext
library". Don't you see how weird that sounds?
libucontext should only be needed for toolchains that don't support
ucontext... and musl right now is declared as
BR2_TOOLCHAIN_HAS_UCONTEXT=y.
But that's wrong as you point out: musl only provides the ucontext_t
definition, but not the functions to manipulate it. So for example, the
existing capnproto package does this:
depends on BR2_TOOLCHAIN_HAS_UCONTEXT
but because musl doesn't really support ucontext, it also does:
# musl doesn't support getcontext/setcontext
ifeq ($(BR2_TOOLCHAIN_USES_MUSL),y)
CAPNPROTO_CONF_ENV += CXXFLAGS="$(TARGET_CXXFLAGS) -DKJ_USE_FIBERS=0"
endif
For a similar reason, libopenssl has to do this:
ifeq ($(BR2_TOOLCHAIN_USES_MUSL),y)
LIBOPENSSL_CFLAGS += -DOPENSSL_NO_ASYNC
endif
ifeq ($(BR2_TOOLCHAIN_HAS_UCONTEXT),)
LIBOPENSSL_CFLAGS += -DOPENSSL_NO_ASYNC
endif
Because libopenssl really uses ucontext, so
BR2_TOOLCHAIN_HAS_UCONTEXT=y isn't enough, it also needs to exclude the
musl case.
Apparently, the only packages for which BR2_TOOLCHAIN_HAS_UCONTEXT kind
of makes sense are libsigsegv libabseil-cpp, as it indeed only needs
ucontext_t, but not the getcontext/makecontext functions.
Still, I would argue that we should change BR2_TOOLCHAIN_HAS_UCONTEXT
to mean that the toolchain defines ucontext_t *and* implements
getcontext/makecontext/setcontext. This implies (1) adding a comment
above the option to explain its semantic and (2) drop the select
BR2_TOOLCHAIN_HAS_UCONTEXT from musl.
Then we can clean up libopenssl and capnproto. php would no longer
fail, because BR2_TOOLCHAIN_HAS_UCONTEXT would no longer be true for
musl.
And finally, we can re-enable php on musl by making use of libucontext.
Do you think you could work on this? It would be nice.
Thanks a lot,
Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 2+ messages in thread