Re: remove intl/ directory?

[Iain Sandoe <idsandoe@googlemail.com>]

> On 23 Jun 2022, at 07:51, Iain Sandoe via Gcc <gcc@gcc.gnu.org> wrote:
> 
>> On 23 Jun 2022, at 05:24, Bruno Haible <bruno@clisp.org> wrote:
>> 
>> Iain Sandoe wrote:
> 
>>> … 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 ;) )
>> 
>> You can get warnings if you _move_ the gettext-runtime directory so that it
>> becomes a sibling directory of 'gcc'. You should *not* get warnings if you
>> create a symlink, sibling of the 'gcc' directory, to the
>> gettext-20220620/gettext-runtime/ directory.
> 
> I did symlink, and agree it should work - I’ll need to try and repeat when next I have some time.
>> 
>>> 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?
>> 
>> On macOS (with .dylib instead of .so) it would probably work.
>> 
>> However, AIX and HP-UX will not work, because (as I understand it) if you want
>> to have a binary, say cc1, which depends on libintl, then
>> - the cc1 that accesses /usr/local/lib/libintl.$suffix
>> and
>> - the cc1 that accesses /home/user/build/gcc-snap/gettext-runtime/intl/.libs/libintl.$suffix
>> must necessarily be different. You cannot just install the second one in
>> public locations, because it will have the wrong shared library filename
>> hardcoded into it. This is why on these systems, libtool has to rebuild
>> executables during "make install".
> 
> Ah, actually a similar situation might apply to the macOS case, you would either need
> to build it “@rpath” and install the library in the exe’s dir or build and install it into
> ‘prefix’ (that puts the full pathname into the dylib, in a similar way to AIX / HP-UX).
> This is also requires a bit of juggling on macOS (I have patches in flight to make all
> the runtimes for GCC built with ‘@rpath’ and using embedded rpaths in exe) hopefully
> for GCC-13
> … so let’s quietly forget the shared case for now...
> 
>> Anyway, you said that for GCC, the important case is to build libintl as a
>> static (non-shared) library.
> 
> Yes, in a 1:1 replacement for ‘intl’ that’s the case, we can figure out shared stuff as a follow-on.
> 
>>> 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)
>> 
>> Are you aware that gettext.m4 already introduces the configure options
>> --with-libintl-prefix[=DIR]  search for libintl in DIR/include and DIR/lib
>> --without-libintl-prefix     don't search for libintl in includedir and libdir
> 
> Hmm - the following cases:
> a) there’s no gettext-runtime in the source tree and the user needs to configure —with-libintl-prefix= 
> b) there is a  gettext-runtime in the source tree and the user decides to configure —with-libintl-prefix= (which will be ignored if we take the way the other in-tree builds are handled as ’status quo’
> c) there is a  gettext-runtime in the source tree  and no —with-libintl-prefix= is given (we expect to pick up the in-tree build silently and automatically).
> 
> … in case (a) we’d need to arrange for the gettext macro to be called in configure, but I don’t think it will play nicely with gettext-sister .. so there’s some work needed here.
> in case (b) I’m not sure what will happen - will the configure for libintl just point the variables to the install suggested?

.. update on (b).
OK, so there are two issues I can see [let’s put the flags pollution issues to one side for now, since people sometimes forget that the configuration namespace is flat and overload save_CFLAGS et. al]

1. —with-libintl-prefix= is not going to work on macOS, when the prefix contains only a convenience lib (which is what I prefer for GCC).
  This is because the configure has no way to know that libintl.a depends on -framework CoreFoundation, AFAICS there’s nowhere it could even look - the info is not in the libtool lib (and that does not seem to get installed anyway for the snapshot) 
  I'd suppose that a shared library would work (since there are no hidden deps) .. 

AFAICT, ‘intl/‘ works OK with this (iff I manually add -framework CoreFoundation to the LDFLAGS) and LIBINTL gets set to the right line for using the installed variant.

2/ .. the current gettext-runtime snapshot does not work, I think because it assumes if we’re not using the in-tree case, then the lib must be coming from libc - which is not the case for most non-glibc clients (so it seems to ignore the —with… and populate the uninstalled-gettext.sh with the in-tree data anyway)

====

(we still need to deal with case (a) but case (b) could be fixable, perhaps at a cost of having to ‘know’ that CoreFoundation is needed on macOS .. perhaps similar cases on other platforms, perhaps not).

Iain

> case (c) works today.
> 
> cheers
> Iain
> 
> 
>