From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) by sourceware.org (Postfix) with ESMTPS id 48F503857376 for ; Thu, 23 Jun 2022 15:50:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 48F503857376 Received: by mail-wr1-x42a.google.com with SMTP id e7so2548660wrc.13 for ; Thu, 23 Jun 2022 08:50:39 -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=G1cSvn0fxHhYauJq5l7kFmJDL2hxrMbPFbOtYce4BnY=; b=P1vloAniWF7vdVr6YWQMJuHqXLWzRBSv3CUpXkxiIF4J7kRIg4CZdwoyujGYuAfYGC uCBKD45Il+OvEc+h+plys1BirTr1t4JsT8kuUyN8zHMqIDlDbsgyscu5ptq8ZydvwGbM f1e8tT7l2t5EoOiBcbx1xB1SHqdhDWHgKrO/zdT3jr1qUutIEsnS5R8Eei+H9j66Qwi4 1960rAijRYAKFpGaU7ubXXQEpKzk4UnMKylQnmcmU6Nf7AkiqNcB/35ErPFkJj7xMs2W cVW18flnVmzeCnSaWpxuDsrn/EOtJ5d7xh05rkSYPDrPviZGE2+hJeJCgKMHdz2yAW7s 9ynA== X-Gm-Message-State: AJIora8x/aZwfh1kHALLKOPL6SRna4lBQ392WS3RVHNA4iayjlvZiQzL lysO1pcyLBbOSXsJi04mPks= X-Google-Smtp-Source: AGRyM1s9DHF6QQFSTzjeBjxi8rqc1Rp/uE/87K/V6BRBGFhKBcLOKB/FDw3jxX76rGqTKMcXaQH4mw== X-Received: by 2002:a5d:688e:0:b0:21b:9d51:25d2 with SMTP id h14-20020a5d688e000000b0021b9d5125d2mr8826844wru.286.1655999437948; Thu, 23 Jun 2022 08:50:37 -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 p13-20020a05600c1d8d00b0039c5645c60fsm10150584wms.3.2022.06.23.08.50.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jun 2022 08:50:36 -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: <0FA9D51E-72ED-46BD-877F-2F9AF8851903@googlemail.com> Date: Thu, 23 Jun 2022 16:50:35 +0100 Cc: GCC Development Content-Transfer-Encoding: quoted-printable Message-Id: <34EE214C-F0D5-42C1-B354-F2B078775F65@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> <0FA9D51E-72ED-46BD-877F-2F9AF8851903@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:50:41 -0000 > On 23 Jun 2022, at 16:40, Iain Sandoe via Gcc wrote: >=20 >=20 >=20 >> 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=99s= o=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? >=20 > .. 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] >=20 > 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 >=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. this ^ is actually inconsistent with the other deps .. as noted below. >=20 > 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) Hmm, brain not working right it seems //// =E2=80=A6 that ^ is the right = behaviour (if we take GMP et al as the model) i.e. we ignore = =E2=80=94with-xxxx-prefix IFF xxxx is present as an in-tree build. >=20 > =3D=3D=3D=3D >=20 > (we still need to deal with case (a) this means using gettext macro or something custom for the case that = there is no in-tree gettext-runtime (no doubt the framework issue could = materialise there too), > 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). >=20 > Iain >=20 >> case (c) works today. >>=20 >> cheers >> Iain >>=20 >>=20 >>=20 >=20