public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Bruno Haible <bruno@clisp.org>
To: Iain Sandoe <idsandoe@googlemail.com>
Cc: GCC Development <gcc@gcc.gnu.org>
Subject: Re: remove intl/ directory?
Date: Thu, 23 Jun 2022 06:24:32 +0200	[thread overview]
Message-ID: <39868934.7CIiGjFlj5@omega> (raw)
In-Reply-To: <6D6D5C3F-0249-4AC7-83BC-7ED96ED3370C@googlemail.com>

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
?

Bruno




  reply	other threads:[~2022-06-23  4:24 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 [this message]
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
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=39868934.7CIiGjFlj5@omega \
    --to=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).