From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout-p-103.mailbox.org (mout-p-103.mailbox.org [80.241.56.161]) by sourceware.org (Postfix) with ESMTPS id 955103858D37 for ; Thu, 16 Nov 2023 19:23:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 955103858D37 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=aarsen.me Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=aarsen.me ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 955103858D37 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=80.241.56.161 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700162591; cv=none; b=CYTEwrTb8Zng+ZH1VgBNNMwYi7CAM8x8xrLHFq08v4aTvtLxnefbXGb9vsAqemOuVBPR7yM9e+SMKAOf8REUZ71x0OwRXsUBB4L4uYfTvd4CtJfUOeXGViy3y1agzLKOUcSqCX+760HxCLohGIf0oNfWHHteYLgEeVGY5tQQBeA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700162591; c=relaxed/simple; bh=lH6njelE5815SCmi6+pNXSBaRNJKxDB9btaZyhqGDIo=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=lHn5U0fpM1b24ksWyXhxYpgLT85kuSbADlRUE+ZwVVT+JCHaEU8aUvEDwM7zPC2Kgwmfvs/N1hlnp3ArhCRu6dR0RSLle9h08M0kvMJ8WQFMEq73FV5hTsCw889bnxpYUXNM8H3eL+temHrHRWD1P7li1o+ZiJBPSQNS9SqNZEk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-103.mailbox.org (Postfix) with ESMTPS id 4SWVLL5BD4z9spg; Thu, 16 Nov 2023 20:23:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aarsen.me; s=MBO0001; t=1700162586; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JCEddvivaslYG3nfoMYbG626T+MYi+TM0vmyA5QKEN8=; b=e0dLA4VmcXzEP5YP4dUFsdWNvOhTqD0eVDcNdn5ZPTt+eqLv1AAv51zgNF9zjmRrth3EHP ip+HXx3bR1oc7JYTmHzvgW/R3bKUeOU/kMAHCjl9uvkR1wWclih2dEaVBz6bIXxzuDqaEO W8mCnMXoOavFJBKHqlvirYidn6vxeBE7vxvsKig/5ZHDlB9IlFfP+B7ZFrLrdCdGEkuIHT mAY/NLqm8PyRXG5PSQ2wjWF1AeBkZrvRMbAFk0u+A3QHRLOjSvDiJcSTOh1czckwkA85uy oQ9hucSLjk6rnp3tKGhKhRb0V64Z62Ms5IZCp7wVIeYX1wskGZhxB3WO/LzD8w== References: <6664645.lMtyQzBqa6@nimes> <86msvdedlt.fsf@aarsen.me> <3917618.lUd5UmjTVT@nimes> From: Arsen =?utf-8?Q?Arsenovi=C4=87?= To: Bruno Haible Cc: Richard Biener , David Edelsohn , GCC Patches , bug-gettext@gnu.org Subject: Re: building GNU gettext on AIX Date: Thu, 16 Nov 2023 20:14:51 +0100 In-reply-to: <3917618.lUd5UmjTVT@nimes> Message-ID: <86pm09cxk7.fsf@aarsen.me> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Rspamd-Queue-Id: 4SWVLL5BD4z9spg X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_INFOUSMEBIZ,RCVD_IN_DNSWL_LOW,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 List-Id: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Bruno Haible writes: > Arsen Arsenovi=C4=87 wrote: >> > * If yes, then the question is how distributors will in general pack= age >> > libintl on AIX. If it's installed in public locations (such as in >> > /opt/freeware/{lib,lib64}/libintl.a on gcc119.fsffrance.org), then= we >> > have a problem: It may cause undefined behaviour in multithreaded >> > packages that use GNU libintl. >> > If you can guarantee that it will be installed in GCC-private dire= ctories >> > (and outside the path where GCC looks for libraries to link with!)= then >> > it would be OK to install such a non-thread-safe libintl. >> > But if you cannot guarantee that, we are in trouble. >>=20 >> The in-tree configuration already passes --disable-shared, so I imagine >> passing --disable-threads would be OK too, for the case that it is >> utilized. (relevant for the latter case: GCC-private build of libintl) > > Yeah, but this affects only those people who use the in-tree build of > the libraries. > > The problem for distributors remains the same: They have a strong tendency > of building libraries indepently, with --enable-shared (so that they can > easily apply fixes without rebuilding the world). These distributors on A= IX > would notice that the GCC configuration attempts to link with "-lintl" > but not with "-lintl -pthread" and thus the configuration detects that NLS > is not usable. > > Arsen: Where in the GCC tree is this part of the GCC configuration? Is it > in some configure.ac owned by GCC, or does it come from gettext.m4 ? See Makefile.def. It specifies a host-gettext module that has the extra flags set. If the in-tree configuration is used, then the uninstalled-config.sh gettext generates is used. See config/gettext-sister.m4. gettext.m4 is unaltered, but it is essentially only used when the gettext in-tree source is not present (because, otherwise, gettext-runtime generates uninstalled-config.sh even if it builds nothing) Hope that answers it. > Bruno =2D-=20 Arsen Arsenovi=C4=87 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOYEARYKAI4WIQT+4rPRE/wAoxYtYGFSwpQwHqLEkwUCZVZsGF8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0RkVF MkIzRDExM0ZDMDBBMzE2MkQ2MDYxNTJDMjk0MzAxRUEyQzQ5MxAcYXJzZW5AYWFy c2VuLm1lAAoJEFLClDAeosSTm3kBANVVkNZJhWcukBN67u/xsJu59JmmyQ68f/O9 XaKiTg/yAQCvtAvBHtFDW52kU8tSPLXyEtUluAJTphexskWyo2jrCw== =WI6k -----END PGP SIGNATURE----- --=-=-=--