From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.25]) by sourceware.org (Postfix) with ESMTPS id 20341381DC78 for ; Thu, 23 Jun 2022 04:24:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 20341381DC78 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=clisp.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=clisp.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1655958273; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=yYgCXpnqZNzAE13IgtejHuS5vG4wSbGCqP5efFOhGSM=; b=Psw6ljgbWJXWbJ+RGWg0eqSQX6Y4yt5rZjtWM3C5B1F6BFBV/I3GX3ZJBof7hPBTv5 KYasG8wFmRFItrOBWdCvFRb4KsVTlfQd7W6nh9/Anq9MDCOPRw7o6Ak7Ndh3UCT/f0RD OXTOpFC8PItsfjhV0Y1+XMxLkh3jM+0H/dDviYnWjywm4RQqZpKW39yjtCUdenf3V2gd DoPFA8zK+nIdscW2bkJ0YnKiB30uOK04xtDq+DzJMSEK2oHpHWLLeeBPUkRu/oKap0fH cqpbnPTXb2J1IPRSgiGB0Aa99zUIVcOKp5YMOGD5x5ATDvuL+DiTbpJHd9GuEtsiP4Kl dIlw== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH0WWb0LN8XZoH94zG6tLj91pDK2rOnz9M72FWrFjJkzkLl8SqcBg==" X-RZG-CLASS-ID: mo00 Received: from omega.localnet by smtp.strato.de (RZmta 47.46.0 AUTH) with ESMTPSA id J5c42fy5N4OWhUC (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Thu, 23 Jun 2022 06:24:32 +0200 (CEST) From: Bruno Haible To: Iain Sandoe Cc: GCC Development Subject: Re: remove intl/ directory? Date: Thu, 23 Jun 2022 06:24:32 +0200 Message-ID: <39868934.7CIiGjFlj5@omega> In-Reply-To: <6D6D5C3F-0249-4AC7-83BC-7ED96ED3370C@googlemail.com> References: <32334822.2dzg3u6YtW@omega> <5937718.KnAXcdumGx@omega> <6D6D5C3F-0249-4AC7-83BC-7ED96ED3370C@googlemail.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_NONE, 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 04:24:37 -0000 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]/..)/gettext= =2Druntime' > . 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 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 not= ed platforms - it would need auto-foo-provided shared lib extension - or th= e 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 w= ant 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/.l= ibs/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=3Dgettext.git;a=3Dcommitdiff;h= =3Dfdc2bd236a6a62b477c1fca4205df10b0e64266b >=20 > IMHO we need to fix this ^ in GCC config - since gettext-runtime accepts = =E2=80=9C=E2=80=94with-pic=E2=80=9D we should amend the GCC configury to pa= ss =E2=80=94with-pic [to GMP et. al. as well, currently to build in-tree wi= th 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 >=20 > 1) add logic [like GMP et. al.] to specify an external source of the libr= ary (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 DIR/= lib --without-libintl-prefix don't search for libintl in includedir and l= ibdir ? Bruno