On Thu, Jun 23, 2022 at 12:25 AM Bruno Haible <br...@clisp.org> wrote:
>
> Iain Sandoe wrote:
> > 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 ...
>
> Good!
>
> > … 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.
>
> > 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".
>
> Anyway, you said that for GCC, the important case is to build libintl as a
> static (non-shared) library.
>
> > > 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]
>
> Indeed, the option '--with-pic' (from libtool) has the same effect as
> '--enable-host-shared'. If you can arrange to pass '--with-pic' instead
> of '--enable-host-shared', I can revert the addition of the option
> '--enable-host-shared' in gettext-runtime/intl from two days ago.
>
> > 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
> ?
>
N.B. that there's already at least one issue open about those flags
that I can think of OTTOMH; it's part of the reason I wanted to go
about updating GCC configury in the first place:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78251
> Bruno
>
>
>
