Re: gettext vs vlc

[Michael Forney <mforney%mforney.org@localhost>]

On 2021-06-04, Thomas Klausner <wiz%netbsd.org@localhost> wrote:
> On Fri, Jun 04, 2021 at 02:22:27PM +0200, Martin Husemann wrote:
>> On Fri, Jun 04, 2021 at 02:18:38PM +0200, Thomas Klausner wrote:
>> > I looked at other packages, and some of them deal with it by removing
>> > this extra check from the configure script. This is hard in this case,
>> > because we run autoreconf in pre-configure.

I thought that the configure cache variable set in
gettext-lib/builtin.mk[0] should be forcing the detection using
configure cache variables. I wonder why it isn't working for VLC.

Investigating a little bit, configure.ac invokes AM_GNU_GETTEXT like this:

AM_GNU_GETTEXT([external], [need-formatstring-macros])

The need-formatstring-macros option means that API version >= 3 is
required. However, gettext-lib/builtin.mk only sets configure cache
variables for version 1 and version 2,  so detection fails.

According to the GNU gettext documentation, API version 3 means that
the implementation supports ISO C99 <inttypes.h> formatstring macros.
VLC requires this since they use macros like `<PRIi64>` in the msgid
strings. However, I'm not sure if there's a good way to test for this
support in a way that could be used in gettext-lib/builtin.mk. As far
as I can tell, by the time that libintl processes the .mo files, the
macros have already been expanded from the .po sources by msgfmt(1),
so I think this is really a matter of whether msgfmt(1) supports the
macros, not libintl. Maybe someone can correct me if I'm wrong here.

So, perhaps a global solution (rather than patching individual package
configure scripts) would be something like this:

diff --git a/devel/gettext-lib/builtin.mk b/devel/gettext-lib/builtin.mk
index 9b56dede4b5..7619761c556 100644
--- a/devel/gettext-lib/builtin.mk
+++ b/devel/gettext-lib/builtin.mk
@@ -126,6 +126,7 @@ CONFIGURE_ENV+=		gt_cv_func_gnugettext1_libintl="yes"
 .        if empty(H_NGETTEXT_GETTEXT:M__nonexistent__) && \
 	    empty(H_NGETTEXT_GETTEXT:M${LOCALBASE}/*)
 CONFIGURE_ENV+=		gt_cv_func_gnugettext2_libintl="yes"
+CONFIGURE_ENV+=		gt_cv_func_gnugettext3_libintl="yes"
 .        endif
 .      else
 CONFIGURE_ENV+=		gt_cv_func_gnugettext_libc="yes"
@@ -133,6 +134,7 @@ CONFIGURE_ENV+=		gt_cv_func_gnugettext1_libc="yes"
 .        if empty(H_NGETTEXT_GETTEXT:M__nonexistent__) && \
 	    empty(H_NGETTEXT_GETTEXT:M${LOCALBASE}/*)
 CONFIGURE_ENV+=		gt_cv_func_gnugettext2_libc="yes"
+CONFIGURE_ENV+=		gt_cv_func_gnugettext3_libc="yes"
 .        endif
 .      endif
 .    endif

It'd be interesting to see how many packages use
need-formatstring-macros (gettext API 3) in their configure.ac script.
Perhaps there are some workarounds that could be reverted.

> autotools use gettext.m4 for detecting libintl. That is part of the
> gettext distribution which also provides libintl. I'm not sure how
> willing they would be to accept a patch for their library that accepts
> another library as a full replacement (where one probably can find
> lots of minor or perhaps major features that NetBSD's libintl does not
> support but gettext libintl does).

Here's some interesting context on this:

On Linux, musl libc provides an alternative implementation of gettext,
which *is* properly detected by gettext.m4 (serial 68 or later [1]).
The way this works is by defining __GNU_GETTEXT_SUPPORTED_REVISION in
libintl.h. Serial 68 of gettext.m4 was committed precisely *to* detect
alternative implementations like musl's without poking at internal GNU
gettext symbols (see the referenced thread in that commit [2]).

However, that commit also claims that NetBSD's and Solaris 7's
implementations are "broken", and that the use of
__GNU_GETTEXT_SUPPORTED_REVISION in gettext.m4 is justified by the
fact that NetBSD does not define this in its libintl.h. So, there is
clearly some tension here. Obviously, NetBSD wants its libintl
implementation to be detected properly by gettext.m4. But it seems
that gettext developers want the exact opposite, though I'm not sure
of the reason.

Does anyone know what (if any) incompatibilities exist between GNU
gettext and NetBSD libintl that might explain this claim of it being
broken? Perhaps, after those were addressed, NetBSD could add a
__GNU_GETTEXT_SUPPORTED_REVISION define to indicate that it is
compatible with GNU gettext and we wouldn't have to worry about
patching configure or setting cache variables to override the result
of the gettext detection.

[0] https://github.com/NetBSD/pkgsrc/blob/49dbd3f708e266bf671e1dd6fb64646338af95d2/devel/gettext-lib/builtin.mk#L124-L129
[1] https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=b67399b4
[2] https://lists.gnu.org/archive/html/bug-gettext/2016-04/msg00000.html