public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Eric Gallager <egall@gwmail.gwu.edu>
To: Bruno Haible <bruno@clisp.org>
Cc: Iain Sandoe <idsandoe@googlemail.com>, GCC Development <gcc@gcc.gnu.org>
Subject: Re: remove intl/ directory?
Date: Thu, 23 Jun 2022 11:13:46 -0400	[thread overview]
Message-ID: <CAMfHzOsWx5uWh6YrVB5J=yLnw=oDgrbPeKN=VuJZMz=z9tiz-g@mail.gmail.com> (raw)
In-Reply-To: <39868934.7CIiGjFlj5@omega>

On Thu, Jun 23, 2022 at 12:25 AM Bruno Haible <bruno@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
>
>
>

  parent reply	other threads:[~2022-06-23 15:13 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-18 17:01 Bruno Haible
2022-06-18 17:42 ` Iain Sandoe
2022-06-18 18:14   ` David Edelsohn
2022-06-19  0:53     ` Bruno Haible
2022-06-19  0:32   ` Bruno Haible
2022-06-19  8:40     ` Iain Sandoe
2022-06-19 20:15       ` Iain Sandoe
2022-06-21  2:05         ` Bruno Haible
2022-06-22 20:21           ` Iain Sandoe
2022-06-23  4:24             ` Bruno Haible
2022-06-23  6:51               ` Iain Sandoe
2022-06-23 15:40                 ` Iain Sandoe
2022-06-23 15:50                   ` Iain Sandoe
2022-06-23 15:13               ` Eric Gallager [this message]
2022-06-20 19:45 ` Eric Gallager
2022-06-21  2:09   ` Bruno Haible

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMfHzOsWx5uWh6YrVB5J=yLnw=oDgrbPeKN=VuJZMz=z9tiz-g@mail.gmail.com' \
    --to=egall@gwmail.gwu.edu \
    --cc=bruno@clisp.org \
    --cc=gcc@gcc.gnu.org \
    --cc=idsandoe@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).