From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) by sourceware.org (Postfix) with ESMTPS id C0EB038582B1 for ; Thu, 23 Jun 2022 15:40:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C0EB038582B1 Received: by mail-wr1-x429.google.com with SMTP id o16so28521251wra.4 for ; Thu, 23 Jun 2022 08:40:04 -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:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ojXVJC38CYirqvdnDTzKrgQtZ2HDVYeAMP0WfvBJ5jo=; b=na6n+bXlliFeCNgKk37L9HtveK7CbJxbtc2LAZKOAmwkKsDRhVwIc5bMTDSPZ3QW0i +eDgoVkt+iw2a9jtPRjAN3AwfqCmtjnMx/zAmOw9MnuVX7w1cCv2Gl9y6Y6/8ZliINb/ +KOxv4B5+rQQ1FKVszzb+bYKrdWkXw7lf1Jc9QvQ6Kw/GT/uMiXiCSrYNzmx7S2TgPVB NsPrWAXK5JG21YxQ7WmIxeJqrribiV1nM+5m+hpYIMaZrJaeeLBYUJQdNIgE7hTsPkuS YKtlWqnW3Irj/aNsEgwAa39Yc4Dzmh3AyzhiDbe8fG7tRhhzuG/DG5QxpOk/wI6Gh01G mKLg== X-Gm-Message-State: AJIora/9S8TEWdLoCTgHbAszIYlEa14xpP4+nszu2iqHWT/Or2bWon9O FF1Gp+J/SSlQOi+tBre+IJo= X-Google-Smtp-Source: AGRyM1sSxFrAuyw+WOEElyojiuKue35eGBSCWTjlG2IPjN0cgHra2+SBTr3ZUFonQzYy6/46Bvp/Qg== X-Received: by 2002:a05:6000:1449:b0:218:6532:403e with SMTP id v9-20020a056000144900b002186532403emr9191101wrx.482.1655998803203; Thu, 23 Jun 2022 08:40:03 -0700 (PDT) Received: from [192.168.1.95] (host81-138-1-83.in-addr.btopenworld.com. [81.138.1.83]) by smtp.googlemail.com with ESMTPSA id n10-20020adffe0a000000b0021b5861eaf7sm20614118wrr.3.2022.06.23.08.40.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jun 2022 08:40:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: remove intl/ directory? From: Iain Sandoe In-Reply-To: <8EDC08C4-3680-49C3-BFEB-9DD6F5425B5E@googlemail.com> Date: Thu, 23 Jun 2022 16:40:01 +0100 Cc: GCC Development Content-Transfer-Encoding: quoted-printable Message-Id: <0FA9D51E-72ED-46BD-877F-2F9AF8851903@googlemail.com> References: <32334822.2dzg3u6YtW@omega> <5937718.KnAXcdumGx@omega> <6D6D5C3F-0249-4AC7-83BC-7ED96ED3370C@googlemail.com> <39868934.7CIiGjFlj5@omega> <8EDC08C4-3680-49C3-BFEB-9DD6F5425B5E@googlemail.com> To: Bruno Haible X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham 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:40:06 -0000 > On 23 Jun 2022, at 07:51, Iain Sandoe via Gcc wrote: >=20 >> On 23 Jun 2022, at 05:24, Bruno Haible wrote: >>=20 >> Iain Sandoe wrote: >=20 >>> =E2=80=A6 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 ;) ) >>=20 >> 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. >=20 > I did symlink, and agree it should work - I=E2=80=99ll need to try and = repeat when next I have some time. >>=20 >>> 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. >>> =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? >>=20 >> On macOS (with .dylib instead of .so) it would probably work. >>=20 >> 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". >=20 > Ah, actually a similar situation might apply to the macOS case, you = would either need > to build it =E2=80=9C@rpath=E2=80=9D and install the library in the = exe=E2=80=99s dir or build and install it into > =E2=80=98prefix=E2=80=99 (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 =E2=80=98@rpath=E2=80=99 and using = embedded rpaths in exe) hopefully > for GCC-13 > =E2=80=A6 so let=E2=80=99s quietly forget the shared case for now... >=20 >> Anyway, you said that for GCC, the important case is to build libintl = as a >> static (non-shared) library. >=20 > Yes, in a 1:1 replacement for =E2=80=98intl=E2=80=99 that=E2=80=99s = the case, we can figure out shared stuff as a follow-on. >=20 >>> I think that we now need to deal with the GCC-side of the configury = =E2=80=A6 >>>=20 >>> 1) add logic [like GMP et. al.] to specify an external source of the = library (when there is no-in-tree source present) >>=20 >> Are you aware that gettext.m4 already introduces the configure = options >> --with-libintl-prefix[=3DDIR] search for libintl in DIR/include and = DIR/lib >> --without-libintl-prefix don't search for libintl in includedir = and libdir >=20 > Hmm - the following cases: > a) there=E2=80=99s no gettext-runtime in the source tree and the user = needs to configure =E2=80=94with-libintl-prefix=3D=20 > b) there is a gettext-runtime in the source tree and the user decides = to configure =E2=80=94with-libintl-prefix=3D (which will be ignored if = we take the way the other in-tree builds are handled as =E2=80=99status = quo=E2=80=99 > c) there is a gettext-runtime in the source tree and no = =E2=80=94with-libintl-prefix=3D is given (we expect to pick up the = in-tree build silently and automatically). >=20 > =E2=80=A6 in case (a) we=E2=80=99d need to arrange for the gettext = macro to be called in configure, but I don=E2=80=99t think it will play = nicely with gettext-sister .. so there=E2=80=99s some work needed here. > in case (b) I=E2=80=99m not sure what will happen - will the configure = for libintl just point the variables to the install suggested? .. update on (b). OK, so there are two issues I can see [let=E2=80=99s put the flags = pollution issues to one side for now, since people sometimes forget that = the configuration namespace is flat and overload save_CFLAGS et. al] 1. =E2=80=94with-libintl-prefix=3D is not going to work on macOS, when = the prefix contains only a convenience lib (which is what I prefer for = GCC). This is because the configure has no way to know that libintl.a = depends on -framework CoreFoundation, AFAICS there=E2=80=99s nowhere it = could even look - the info is not in the libtool lib (and that does not = seem to get installed anyway for the snapshot)=20 I'd suppose that a shared library would work (since there are no = hidden deps) ..=20 AFAICT, =E2=80=98intl/=E2=80=98 works OK with this (iff I manually add = -framework CoreFoundation to the LDFLAGS) and LIBINTL gets set to the = right line for using the installed variant. 2/ .. the current gettext-runtime snapshot does not work, I think = because it assumes if we=E2=80=99re not using the in-tree case, then the = lib must be coming from libc - which is not the case for most non-glibc = clients (so it seems to ignore the =E2=80=94with=E2=80=A6 and populate = the uninstalled-gettext.sh with the in-tree data anyway) =3D=3D=3D=3D (we still need to deal with case (a) but case (b) could be fixable, = perhaps at a cost of having to =E2=80=98know=E2=80=99 that = CoreFoundation is needed on macOS .. perhaps similar cases on other = platforms, perhaps not). Iain > case (c) works today. >=20 > cheers > Iain >=20 >=20 >=20