All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] musl/gettext issue
Date: Fri, 18 Sep 2015 09:41:02 +0200	[thread overview]
Message-ID: <20150918094102.10d6c65e@free-electrons.com> (raw)
In-Reply-To: <55FB3E49.5050606@mind.be>

Hello,

On Fri, 18 Sep 2015 00:27:21 +0200, Arnout Vandecappelle wrote:

> >  1/ Simply do not allow the GNU gettext package to be built with glibc
> >     and musl since they provide the gettext functionality internally.
> 
>  Problem: something like ecryptfs-utils, which needs the gettext program at
> runtime...

Ah, right, correct.

> >     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.
> 
>  This one could perhaps be solved by adding a BR2_HAS_GNU_GETTEXT. But again, of
> course, it must be possible to select gettext in that case.

Indeed.

> >  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.
> 
>  That sounds like a bad idea. What's the point of using musl if you're going to
> add a bunch of GNU extensions to it?

Absolutely, hence me not wanting to do something like that.

>  Another option is that we add a different flag to indicate the dependency on
> libintl:
> 
> config BR2_PACKAGE_GETTEXT_WITH_LIBINTL
> 	bool
> 	default y
> 	depends on BR2_PACKAGE_GETTEXT
> 	depends on BR2_STATIC_LIBS

Why this depends on BR2_STATIC_LIBS ? Linking against libintl is also
needed in dynamic linking scenarios.

The build failure of
http://autobuild.buildroot.org/results/ede/ede5ee3316ea2b6790dcb930a6bc71adc8922bfc/
requires linking with libintl, even if it's a dynamic linking
configuration.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

  reply	other threads:[~2015-09-18  7:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-16 20:16 [Buildroot] musl/gettext issue Thomas Petazzoni
2015-09-17 22:27 ` Arnout Vandecappelle
2015-09-18  7:41   ` Thomas Petazzoni [this message]
2015-09-18 14:00     ` Arnout Vandecappelle
2015-10-04  9:30   ` Peter Korsgaard
2015-10-11 21:21 ` Jörg Krause
2016-01-15  1:19 ` Jörg Krause
2016-01-26 21:25 ` Bernd Kuhls
2016-01-26 21:29   ` Thomas Petazzoni
2016-01-30 22:52     ` Bernd Kuhls

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150918094102.10d6c65e@free-electrons.com \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.