A new GettextRuntime_jll package

[nhz2]

Usually, the full Gettext package is not needed at runtime.

For example, glib requires using the gettext() function provided by libintl or the system.

Quoting the "PACKAGING" file in Gettext:

Packaging hints for binary package distributors

Although the source of the gettext package comes as a single package,
I recommend that in distributions of binary packages the installed files
be split into three packages:

gettext-runtime
Contents: Runtime libraries and programs.
Audience: Anyone who wants to run internationalized programs.

libtextstyle
Contents: Text styling library.
Audience: Anyone who wants to run or develop programs that produce
styled text, to be displayed in a terminal emulator.

gettext-tools
Contents: Tools and documentation for developers and translators.
Audience: Anyone who wants to develop or localize internationalized
programs, i.e. developers and translators.
Dependencies: requires gettext-runtime.

The 'gettext-runtime' binary package is much smaller than the 'gettext-tools'
binary package (420 KB versus 5.5 MB). I recommend to include it in the default
installation list, like GNU 'coreutils'; in fact, the runtime programs are
utilities for sh programs.

Gettext_jll.jl currently only provides: LibraryProduct: libgettext

This is part of gettext-tools.

Can I create a new package GettextRuntime_jll.jl with only the runtime?

The runtime includes lib/libintl, lib/libasprintf, and a few executables listed in "PACKAGING" file in Gettext.

xref: #792

[nhz2]

Also xref: Julia-i18n/Gettext.jl#5 #8289

[stevengj]

It looks like libintl is being built without wbindtextdomain on Windows, and it's causing Julia-i18n/Gettext.jl#5 to struggle with Unicode pathnames on Windows.

I'm guessing that this is a cross-compiling snafu? All of the Windows-specific stuff in the gettext source code is conditionally compiled with:

#if defined _WIN32 && !defined __CYGWIN__

Shouldn't _WIN32 be set by the cross-compiler? Or is it setting __CYGWIN__ too?

[stevengj]

Looks like binarybuilder uses cygwin, which is the problem here.

We may need to manually unset the __CYGWIN__ preprocessor symbol? But this might be dangerous because it could effect system headers. Might be safer to do a search-replace to get rid of the !defined __CYGWIN__ checks in the gettext source code.

Looking at the Gettext ChangeLog, it seems like some of the windows stuff was disabled a long time ago on Cygwin because of flaky Cygwin support for Win32 functions that may no longer be a problem.

[giordano]

We don't use cygwin, this is a Linux system with mingw toolchain.

[stevengj]

So then why isn’t wbindtextdomain in the binary?

[giordano]

As far as I can tell, that's a macro: https://github.com/autotools-mirror/gettext/blob/7185ecbc550c0b504ab5ba77b262acaeaf2b198e/gettext-runtime/intl/libgnuintl.in.h#L351

[stevengj]

If that were true, then bindtextdomain would also be a macro. I don't think that _INTL_REDIRECT_MACROS is true.

[nhz2]

Related: gettext-rs/gettext-rs#79

From what I can tell, all the functions have a prefix of "libintl_"
https://github.com/autotools-mirror/gettext/blob/v0.22.4/gettext-runtime/intl/libgnuintl.in.h#L61-L67
But there is also a set of unprefixed functions (which doesn't include wbindtextdomain) in https://github.com/autotools-mirror/gettext/blob/v0.22.4/gettext-runtime/intl/intl-compat.c for some reason.

[stevengj]

Okay, libintl_wbindtextdomain seems to work. But my test with a Unicode pathname is still failing on Windows for unrelated reasons 😢 . Fixed.

For consistency, I just prefixed all of the ccall identifiers with libintl_.