From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) by sourceware.org (Postfix) with ESMTPS id 52BA1384645E for ; Thu, 23 Jun 2022 06:51:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 52BA1384645E Received: by mail-wr1-x432.google.com with SMTP id n1so26252723wrg.12 for ; Wed, 22 Jun 2022 23:51:32 -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=paQfpuDymuGYUaCSK2JWeIpDYaqZnFMTrB+I54r4upc=; b=keEIF4RM0atgvgtukZJF1nAUWJxsV2prvdaPCz7YwYwoPDAJV4ueEazu1/+D/PFz1c WaqNLK0z/A7DkDqYhXKmgKT3yTw5Z10COOEa+8nSEJq0FlStK3TPEt4yhtfoeFZymGjL LHv+ysy+arUKFY2XmgtI2gCEMTUFPA0O+uGKJDhD1CWixnpdoQBu3+3HtgCtBE0Rz1T6 InTVKLZY5fW1mXMonMXUuugPBpNaDKLvvojfsqcGcO8iRXoTRiadEa1uqVbBodxruos7 BRgBoNUm6UJx8RNECduOk71T6g9Zy0X6yKCqPLMSIaMaV1jnGW0UMPZWLMu86da48zFC UMFg== X-Gm-Message-State: AJIora+xvBNP5Ugu1BFtx/aFx0J48NXmN8i3PrKOixooCq/hC7u+IFkn jzz6ILk9T0aG0pbNDIYiGI8= X-Google-Smtp-Source: AGRyM1v5W+RVE823lfRSb1K3uBaycvBVqMVNNFPEI+BPQWUbMVNITlLTqPMTtF7NThcyKjL5TnAo9Q== X-Received: by 2002:a05:6000:1ac8:b0:21b:9236:6207 with SMTP id i8-20020a0560001ac800b0021b92366207mr6522427wry.123.1655967090388; Wed, 22 Jun 2022 23:51:30 -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 m22-20020a05600c3b1600b00397402ae674sm2010477wms.11.2022.06.22.23.51.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jun 2022 23:51:29 -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: <39868934.7CIiGjFlj5@omega> Date: Thu, 23 Jun 2022 07:51:29 +0100 Cc: GCC Development Content-Transfer-Encoding: quoted-printable Message-Id: <8EDC08C4-3680-49C3-BFEB-9DD6F5425B5E@googlemail.com> References: <32334822.2dzg3u6YtW@omega> <5937718.KnAXcdumGx@omega> <6D6D5C3F-0249-4AC7-83BC-7ED96ED3370C@googlemail.com> <39868934.7CIiGjFlj5@omega> 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 06:51:34 -0000 Hi Bruno, > On 23 Jun 2022, at 05:24, Bruno Haible wrote: >=20 > Iain Sandoe wrote: >> =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. 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". 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... > Anyway, you said that for GCC, the important case is to build libintl = as a > static (non-shared) library. 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. >> 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 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). =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? case (c) works today. cheers Iain