> On 23 Jun 2022, at 16:40, Iain Sandoe via Gcc <gcc@gcc.gnu.org> wrote:
>
>
>
>> 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 <br...@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.
this ^ is actually inconsistent with the other deps .. as noted below.
>
> 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)
Hmm, brain not working right it seems //// … that ^ is the right behaviour (if
we take GMP et al as the model) i.e. we ignore —with-xxxx-prefix IFF xxxx is
present as an in-tree build.
>
> ====
>
> (we still need to deal with case (a)
this means using gettext macro or something custom for the case that there is
no in-tree gettext-runtime (no doubt the framework issue could materialise
there too),
> 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
>>
>>
>>
>
