From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 89C351F45A for ; Sat, 29 Oct 2022 21:48:58 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=clisp.org header.i=@clisp.org header.b="MJSo5OgP"; dkim-atps=neutral Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oothE-0006ZU-Gq; Sat, 29 Oct 2022 17:48:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oothB-0006ZF-Kw; Sat, 29 Oct 2022 17:48:49 -0400 Received: from mo4-p01-ob.smtp.rzone.de ([85.215.255.54]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ooth7-0007Nl-DG; Sat, 29 Oct 2022 17:48:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1667080121; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:To:From:Cc:Date:From: Subject:Sender; bh=JU/CPUP5mFzD91il3fG6i29rdemVbox6HcwzLq1Vgxk=; b=MJSo5OgPVm9wlI1SWQ3o3Exd/OY6izWsgzmsIzqMFJiJwoUTe5ULegRKrhCptip6pa QGaDhuVu+Xj07hEUXiuPEjgH8weEsGiTIopK9lwCBgmuyxo360Ks3oVzcPuq7g8rfvfQ okz4cFQwvfg6Tz1lli2be0BCs1uX0XMPhjzWt/7sAbYsJSZVgNF5V6RiZXzxlScHG2/B WYDusnyCTg+4q8ZaznehPRZziM364U+DzvpgQkUoFodr+uHyESmXRdljxIu03d+SDvFK SpDdkNAh+iNqjE0S4Zou/A/hzulzKcQAn5X1bkzIBUTeh04pahk3wkWsdtIfKD2gWrC3 capg== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH0WWb0LN8XZoH94zq68+3cfpPD2feZnFI1EukB7hdjgBUPf8RCcA==" X-RZG-CLASS-ID: mo00 Received: from nimes.localnet by smtp.strato.de (RZmta 48.2.1 AUTH) with ESMTPSA id v9c7e6y9TLmfW7W (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Sat, 29 Oct 2022 23:48:41 +0200 (CEST) From: Bruno Haible To: Gavin Smith , bug-gnulib@gnu.org, bug-texinfo@gnu.org Subject: Re: Avoid gnulib redefinitions - MDA Date: Sat, 29 Oct 2022 23:48:41 +0200 Message-ID: <1791297.4MS8fQxZnU@nimes> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Received-SPF: none client-ip=85.215.255.54; envelope-from=bruno@clisp.org; helo=mo4-p01-ob.smtp.rzone.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "bug-gnulib" Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Hi Gavin, > Previously in the Texinfo project, we added variables to configure.ac to > stop the redefinition of "Microsoft deprecated aliases": > > https://lists.gnu.org/archive/html/bug-gnulib/2021-03/msg00004.html > > For example, GNULIB_MDA_FDOPEN to stop the redefinition of 'fdopen'. > > Recently, it was reported that this didn't work when building on > MS-Windows. I found that it should maybe be GL_GNULIB_MDA_FDOPEN instead: > > https://lists.gnu.org/archive/html/bug-texinfo/2022-10/msg00180.html > > I had identified the following change as potentially being responsible: > > 2021-04-11 Bruno Haible > > Support several gnulib-tool invocations under the same configure.ac. > Reported by Reuben Thomas in > . > This is done by defining the Gnulib module indicator variables per > gnulib-tool invocation. So that a generated .h file is no longer > influenced by the set of modules used in other gnulib-tool invocations. > * gnulib-tool (func_compute_include_guard_prefix): Set > module_indicator_prefix. > > Should we use the variables with the GL_ prefix now and is this something > we can rely on? Or should we simply #undef fdopen and the other symbols? The way to avoid a particular MDA symbol definition (GNULIB_MDA_FDOPEN=0 before April 2021, GL_GNULIB_MDA_FDOPEN=0 after April 2021) is an undocumented functionality. It is not expected that it will break soon. The 2021-04-11 change that you cited above was a once-in-a-decade change. But it may break theoretically, since it is not in the form of a stable functionality. (A stable, supported functionality would be something like a gnulib-tool option and/or a module name.) > We don't use fdopen, putenv or mktemp in the library being built, but these > are pulled in by Gnulib dependencies. > > I don't know if it is possible at all but it would seem to be better > for Gnulib not to redefine symbols that are not actually used in the > program. I chose not to do so for the following reasons: * These "Microsoft deprecated aliases" are deprecated. This means, they can break at any moment, causing bug reports regarding all released tarballs. It is better (for 99% of the package maintainers) to have this problem dealt with, in advance, _before_ it becomes an FTBFS. * Already now, these "Microsoft deprecated alias" symbols cause link errors in a particular native Windows platform. Namely, when clang-cl is used in combination with the MSVC header files. (clang for Windows does not come with its own Win32 API header files, like mingw does.) * There are 50 "Microsoft deprecated aliases". If Gnulib would use an opt-in approach for these, i.e. if the package maintainer would have to enumerate all of these that their package uses one-by-one, it would be too much maintenance effort / too high risk of mistake. * Given that in this list you find symbols like 'open' / 'creat' / 'close' and 'strdup', most programs that rely on POSIX APIs need the "Microsoft deprecated aliases" handling. Only programs that use only ISO C APIs wouldn't care; but these programs usually don't need Gnulib anyway. So, to me, an opt-out approach seems to be the best approach here. It broke because the hint that I gave you in March 2021 was not a stable API. But we don't have stable APIs for everything. Bruno