From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) by sourceware.org (Postfix) with ESMTPS id 9630B38582A3 for ; Thu, 23 Jun 2022 15:13:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9630B38582A3 Received: by mail-vk1-xa2b.google.com with SMTP id j26so4993023vki.12 for ; Thu, 23 Jun 2022 08:13:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=H4hWEkPFpZfkFsnc0wiXFKeQ9J8xD+BaQyOvOwSTazc=; b=v/JZrYYjjcC4EMsABeRhBjRJjXv4iww6Hv1B34Q/htyDhNXFKGyfWZ+H6AlSpIbogE OgqoVkfJiuRuMBSrhTWT1F/mwUw6LCWYy1hTO9NB+LS/0h95UjCaOGgErme/af3YWcBU qN6Dtd6SOvFSErzPr0+EIAz0akfYtEKNqVCKx8u5+RQiOmBrrvKTmoQ5E43wbOu7r/O4 NkGxptwHzscOotUPLqvtbZR6p0y65uhq04bwCTV2p6SAkLM2+vQ+WT2c/8sUUV1QZoIu QXFCxYNJpMRgSWyy8Mq1watTmO8AIkQfV1kRSB44iyF2Mpbzist/AIhKcJr/KMatl0aA 7RRw== X-Gm-Message-State: AJIora+RcEatKxJIJL97zlBGXeL138VqO/LF3MxhSss/Jzx2Cs96strA nqleQFe/11CXTMWoADULY7/MaXOOD5AQK6QsMuoaMw== X-Google-Smtp-Source: AGRyM1t6y7Co/QaO+8z9cAOH7z0pj99966ed+1R0C6uJiSYQiJw0/j0rfNZPpoFKii1WyQnekkRP4hIef+6UeHYx4Sk= X-Received: by 2002:a05:6122:25b:b0:36c:5f1a:d94b with SMTP id t27-20020a056122025b00b0036c5f1ad94bmr8074187vko.31.1655997237490; Thu, 23 Jun 2022 08:13:57 -0700 (PDT) MIME-Version: 1.0 References: <32334822.2dzg3u6YtW@omega> <5937718.KnAXcdumGx@omega> <6D6D5C3F-0249-4AC7-83BC-7ED96ED3370C@googlemail.com> <39868934.7CIiGjFlj5@omega> In-Reply-To: <39868934.7CIiGjFlj5@omega> From: Eric Gallager Date: Thu, 23 Jun 2022 11:13:46 -0400 Message-ID: Subject: Re: remove intl/ directory? To: Bruno Haible Cc: Iain Sandoe , GCC Development Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, JMQ_SPF_NEUTRAL, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2022 15:14:01 -0000 On Thu, Jun 23, 2022 at 12:25 AM Bruno Haible 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=3D'ifelse([$1],,[${top_builddir}/..],[$1]/..)/gette= xt-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! > > > =E2=80=A6 although now I see some configure warnings about not being ab= le 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 yo= u > 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 n= oted platforms - it would need auto-foo-provided shared lib extension - or = the equivalent to be used. > > =E2=80=A6 is there any reason that all platforms with non-=E2=80=99so= =E2=80=99 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 gettex= t: > > > https://git.savannah.gnu.org/gitweb/?p=3Dgettext.git;a=3Dcommitdiff;h= =3Dfdc2bd236a6a62b477c1fca4205df10b0e64266b > > > > IMHO we need to fix this ^ in GCC config - since gettext-runtime accept= s =E2=80=9C=E2=80=94with-pic=E2=80=9D we should amend the GCC configury to = pass =E2=80=94with-pic [to GMP et. al. as well, currently to build in-tree = with host-shared, needs a manual =E2=80=94with-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 =E2= =80=A6 > > > > 1) add logic [like GMP et. al.] to specify an external source of the li= brary (when there is no-in-tree source present) > > Are you aware that gettext.m4 already introduces the configure options > --with-libintl-prefix[=3DDIR] search for libintl in DIR/include and DI= R/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=3D78251 > Bruno > > >