Hi Bruno, > 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? case (c) works today. cheers Iain
