Re: remove intl/ directory?

[Iain Sandoe <idsandoe@googlemail.com>]

Hi Bruno,

+1 on the C reasons for removing intl.
(however, once we have a rough working patch, it would still need buy-in from GDB + binutils)

> On 21 Jun 2022, at 03:05, Bruno Haible <bruno@clisp.org> wrote:

>> So, indeed, part of this is quite straight forward - we can amend the Makefile.def
>> to specify that GCC should use gettext-runtime (it will be used if the directory is
>> present, otherwise there will be no intl support).
>> 
>> The tricky part is that we need to use the runtime ‘uninstalled’, and here is where
>> intl is helpful - it provides a ‘config.intl’ that can be sourced via gettext-sister.m4
>> to provide the neccessary configure input to directories that want to use intl.
>> 
>> I have hacked a change to gettext-sister.m4 that fishes the same information out
>> of gettext-runtime/Makefile (as configured in $build) - obviously this is going to be
>> fragile w.r.t different versions of gettext-runtime (so I am not suggesting this is a
>> viable patch) - simply something to illustrate what needs to be figured out.
>> 
>> So - the changes are in Makefile.def and config/gettext-sister.m4 (the patch includes
>> the regenerated files for convenience of use).
>> 
>> I tried this with gettext-0.21 on macOS 10.15 and, AFAICT, it DTRT - but needs work
>> to resolve the main point above.
> 
> Excellent! Glad to see that you are going ahead so quickly.
> 
> I have now added the necessary support for this "uninstalled" situation from
> the gettext side:
> https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=6f048e30a88282ed6712ce8d6000302fd287daad
> This is in a form that is maintainable from gettext's side.
> 
> I believe that with this, you can change these lines from gettext-sister.m4
> 
>  BUILD_INCLUDED_LIBINTL=`grep BUILD_INCLUDED_LIBINTL ../gettext-runtime/Makefile|sed s/BUILD_INCLUDED_LIBINTL\ =\ //`
>  USE_NLS=`grep USE_NLS ../gettext-runtime/Makefile|sed s/USE_NLS\ =\ //`
>  LIBICONV=`grep ^LIBICONV ../gettext-runtime/Makefile|sed s/LIBICONV\ =\ //`
>  INTL_MACOSX_LIBS=`grep ^INTL_MACOSX_LIBS ../gettext-runtime/Makefile|sed s/INTL_MACOSX_LIBS\ =\ //`
>  XGETTEXT=`grep XGETTEXT ../gettext-runtime/Makefile|sed s/XGETTEXT\ =\ //`
>  GMSGFMT=`grep GMSGFMT ../gettext-runtime/Makefile|sed s/GMSGFMT\ =\ //`
>  POSUB=`grep POSUB ../gettext-runtime/Makefile|sed s/POSUB\ =\ //`
>  LIBINTL="\${top_builddir}/../gettext-runtime/intl/.libs/libintl.a $LIBICONV $INTL_MACOSX_LIBS"
>  INCINTL="-I\${top_builddir}/../gettext-runtime/intl"
> 
> roughly to this:
> 
>  relative_builddir='${top_builddir}/../gettext-runtime'
>  . ${top_builddir}/../gettext-runtime/uninstalled-config.sh

Yes (
# We can use an in-tree build of libintl.
if test -f  ifelse([$1],,[../gettext-runtime],[$1])/uninstalled-config.sh; then
  relative_builddir='ifelse([$1],,[${top_builddir}/..],[$1]/..)/gettext-runtime'
  .  ifelse([$1],,[../gettext-runtime],[$1])/uninstalled-config.sh
elif test -f  ifelse([$1],,[../intl],[$1])/config.intl; then
  .  ifelse([$1],,[../intl],[$1])/config.intl
fi
)
and it works ...

… although now I see some configure warnings about not being able to access build-aux (which I do not recall seeing with the previous hack - but that could be just bad memory ;) )

-----

FWIW this following snippet would be just as broken on macOS as other noted platforms - it would need auto-foo-provided shared lib extension - or the equivalent to be used.
…  is there any reason that all platforms with non-’so’ suffixes would not work with that change?

+# LIBINTL is a set of compiler options, to use when linking without libtool,
+# that ensures that the library that contains the *gettext() family of functions
+# gets found.
+if test @USE_INCLUDED_LIBINTL@ = yes; then
+  if test '@ENABLE_SHARED@' = yes; then
+    # NB: This case is not supported on AIX and HP-UX.
+    LIBINTL="${relative_builddir}/intl/.libs/libintl.so -Wl,-rpath,${relative_builddir}/intl/.libs @LIBICONV@ @INTL_MACOSX_LIBS@"
+  else
+    LIBINTL="${relative_builddir}/intl/.libs/libintl.a @LIBICONV@ @INTL_MACOSX_LIBS@"
+  fi
+else
+  # The functionality is provided by libc.
+  LIBINTL=
+fi

> There is also a GCC specific quirk, that I upstreamed into GNU gettext:
> https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=fdc2bd236a6a62b477c1fca4205df10b0e64266b

IMHO we need to fix this ^ in GCC config - since gettext-runtime accepts “—with-pic” we should amend the GCC configury to pass —with-pic [to GMP et. al. as well, currently to build in-tree with host-shared, needs a manual —with-pic on the configure too]

I added a change that looks at the [host-shared] flag in the top-level configure, it just needs to be moved and used to add the —with-pic flags where needed (where ‘just’ is more than 5mins work, and needs testing widely …)
 
>> P.S. I am slighty surprised that configuring with —disable-java does not appear to stop
>> the on-screen popup appearing that tells me I need to install Java to use this … that
>> would be an irritation when using this on a headless box.
> 
> Thanks for reporting this; it should be fixed now, through
> https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=971dcbdbebb05d7ae8aa6399a0c79442fa996c5c

yes, thanks!

> You find a tarball from the current gettext git, that contains all these
> changes, in https://alpha.gnu.org/gnu/gettext/gettext-20220620.tar.gz .
> Obviously, the GCC documentation will have to say that all this works only
> with GNU gettext 0.22 or newer, i.e. after I make the next release.

Indeed, we can set a minimum version.

I think that we now need to deal with the GCC-side of the configury …

1) add logic [like GMP et. al.] to specify an external source of the library (when there is no-in-tree source present)
2) if the in-tree source is available, I believe that the current status-quo is that it will override anything set with (1).

(1) might be slightly more tricky to do than GMP et. al. since they operate by jamming the -I, -L and -lxxx into the CFLAGS/LDFLAGS, where the in-tree intl scheme inserts the information into the configured variables, so we would need to emulate that for an installed libintl.

-----

Anyways, it’s 10.4 release time so all my resources (machines and time) are tied up with that - so probably nothing happening on this (from me at least) until that release (and my darwin-specific follow-on) is done.

thanks for working on this!
Iain