[Buildroot] musl/gettext issue

Jörg Krause joerg.krause at embedded.rocks
Fri Jan 15 01:19:55 UTC 2016


Hello,

On Mi, 2015-09-16 at 22:16 +0200, Thomas Petazzoni wrote:
> Hello,
> 
> Today, I started looking at:
> 
>    http://autobuild.buildroot.org/results/ede/ede5ee3316ea2b6790dcb93
> 0a6bc71adc8922bfc/build-end.log
> 
> Which, in appearance, seems to be the traditional missing -lintl when
> linking. But further investigation has revealed a slightly more
> complicated problem: how do we handle GNU gettext vs. musl.
> 
> Until, we were handling GNU gettext for glibc and uClibc:
> 
>  * With glibc, the gettext handling is built into the C library. So
> the
>    separate GNU gettext package (for the target) is not needed, and
> if
>    it ever gets built, it detects that the C library has the
> necessary
>    features, and therefore it doesn't build/install a libintl.so
>    library and its header files.
> 
>  * With uclibc, the gettext handling is not part of the C library, so
>    we have to build the GNU gettext package when gettext support is
>    needed. In this case, the GNU gettext package detects that the C
>    library does not provide the gettext functionality, and it will
>    build/install libintl.so and its header files.
> 
> This is why we have BR2_NEEDS_GETTEXT which is true when we use
> uClibc
> and false when we use uClibc, and BR2_NEEDS_GETTEXT_IF_LOCALE which
> is
> true when BR2_NEEDS_GETTEXT is true (i.e uClibc) *and* locale support
> is enabled.
> 
> So far, so good.
> 
> Now, enter musl. It does have an internal gettext implementation.
> However, it is not recognized by GNU gettext has a correct
> implementation, so when you build GNU gettext in a musl system, it
> does
> build/install libintl.so and its header files.
> 
> So for httping, two scenarios are possible:
> 
>  1/ httping is built alone against musl. No problem: the gettext
>     functions are part of the C library, everything works fine.
> 
>  2/ httping is built *after* GNU gettext has been built. Since GNU
>     gettext will replace the libintl.h of musl by its own one, the
>     symbols from the GNU gettext libintl.so will be used, so we must
>     link with -lintl explicitly. Which we are not doing, since
>     htting.mk does:
> 
>        $(if $(BR2_NEEDS_GETTEXT),-lintl)
> 
>     And BR2_NEEDS_GETTEXT is false for musl.
> 
> So, I initially tried:
> 
> -       $(if $(BR2_NEEDS_GETTEXT),-lintl)
> +       $(if $(BR2_PACKAGE_GETTEXT),-lintl)
> 
> With the reasoning that if GNU gettext is available, we want to use
> it,
> and if it's not available, then we'll not use it.
> 
> But that doesn't work with a glibc configuration: BR2_PACKAGE_GETTEXT
> can be enabled, but we don't have a libintl library, because GNU
> gettext doesn't build one in a glibc configuration. We try to link
> against libintl, but it's not there, and the build fails.
> 
> So, I see two possible options here:
> 
>  1/ Simply do not allow the GNU gettext package to be built with
> glibc
>     and musl since they provide the gettext functionality internally.
> 
>     The only problem with this approach is that while httping is
> happy
>     with the POSIX compliant gettext functionality of musl, some
> other
>     programs such as Bison
>     (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786885) will
>     really need GNU gettext functionality.
> 
>  2/ Allows force to use GNU gettext in musl configurations. This
> simply
>     consists in:
> 
>  config BR2_NEEDS_GETTEXT
>         bool
> -       default y if BR2_TOOLCHAIN_USES_UCLIBC
> +       default y if BR2_TOOLCHAIN_USES_UCLIBC ||
> BR2_TOOLCHAIN_USES_MUSL
> 
>      I have tested this solution and it does work (obviously).
> 
>      The drawback is obviously that we are going to build/install GNU
>      gettext even for cases where the internal gettext implementation
>      of musl would have been sufficient.
> 
> Do you see some other options? Any opinion between the two proposed
> options?

How do we deal with this issue?

Jörg


More information about the buildroot mailing list