From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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.6 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 7EB741F47C for ; Thu, 26 Jan 2023 10:20:14 +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.a=rsa-sha256 header.s=strato-dkim-0002 header.b=q7Etz10G; dkim-atps=neutral Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pKzMI-0002tR-Uc; Thu, 26 Jan 2023 05:19:55 -0500 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 1pKzM9-0002tA-T7 for bug-gnulib@gnu.org; Thu, 26 Jan 2023 05:19:46 -0500 Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.162]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pKzM7-0008RF-Jt for bug-gnulib@gnu.org; Thu, 26 Jan 2023 05:19:45 -0500 ARC-Seal: i=1; a=rsa-sha256; t=1674728380; cv=none; d=strato.com; s=strato-dkim-0002; b=mDMqTOGvygulnOsNqKgtyHHwMFotK+UcZn3+HVDiI9QFVXVARQjvWeWJ5WPnbV12Lr jSwEFUXN1eoNzFqtf7zCZWclbGrUAPe06vYwn+lggYcW9C+IUKKBWyRcaD4oC6Go771n 6DfdYFpsoOTKCqsckSoFEfsnPaPRDjMf1DYN729uXPLjAV4F4Fzqkxremh7Z2KcmcfvA zuiw6aNVkCFgN1f5aKhQzoZ7vBPi70dmc+YIQ0PjiEOd1wjR1yfB4nuAQBSxHHXONvSJ 8Q+i4/cgFn9Y02CEBz4Ut+Mk5m9fyfiq3ztuLZthoJPuI3OuhVc6YWEIfdlW+JG+Z4PM cHmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1674728380; s=strato-dkim-0002; d=strato.com; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=uXlnqpCmenwq8ot9JWZNdzOvTTjfhzl4lxhwIUzJQAU=; b=WZcAU22vevJ4tBQszwlFvuOjyLHN9PTXtQbHFUcdECm/9xDwCfXq6UbXiJHoY0FBx9 MXlBkgj8Ot3DGoeL4e0ulzmWGFPFoIJpPpvQ9AJMZYG/v15/jBcJH0jakjSTBFF9U5Bc zen4Nibf7HI15vjUFxTEhFha1gi10p7KrQvG2xZa0urESCjIHnOQ2bEdhINEXqQYpGXR tKR/MrpEspvK2JvQCsPMTIjfo1czgV76NSw8LgfjEL0bX8dUlV0sqPgW6mcupNzEqBAF TfjWD2BjAdSloy2jW0UWILoYGdr8TAVtSrmc4rHyt9b0B8nGZECJiZTN09lQTC49SdFP 6M7w== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1674728380; 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=uXlnqpCmenwq8ot9JWZNdzOvTTjfhzl4lxhwIUzJQAU=; b=q7Etz10GQQKKIqGbJnWCcwxgpxha+wGd7uaQAj0Y4Hb4uUzOVwB6gM9/7FcjRKNWYx PyzgEbAHKmD/+lPiCybk+ODnLA//wGz5dfkW4oOPv2PQxE8ZAsHkkhRsKNaRdz0wI/iK MTLTmS2Tn/5Qvqeh8NlPerFsgax/dvlmawjuMSPBd5v0tjQMGVZB1p6jrkFx9aQ/aaF+ q39es8NpTJsWjhCGXJL5JPFk2E+8Er2qir2gEGbuW9G59cPqWhUc7E2PCptU8QC0qspa 9iQoSKzPVVzROH6lsiy51QyQ3wZhn1xC6bk+X6pkfyVFTkkdOsjoKIITqNpje9QjBWBp LeLA== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH0WWb0LN8XZoH94zq68+3cfpPE3/AkhaePDzS2RsxjOA78fax83g==" Received: from nimes.localnet by smtp.strato.de (RZmta 49.2.2 AUTH) with ESMTPSA id 098542z0QAJeD9W (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Thu, 26 Jan 2023 11:19:40 +0100 (CET) From: Bruno Haible To: "(GalaxyMaster)" Cc: bug-gnulib@gnu.org Subject: Re: backupfile and backup-rename are introducing the same object to make Date: Thu, 26 Jan 2023 11:19:39 +0100 Message-ID: <3002907.JBgfCQoYGg@nimes> In-Reply-To: <01000185ecf1f354-7785c91c-52c3-46f5-b2e7-7685f32c831f-000000@email.amazonses.com> References: <01000185e8d1146f-84242ea5-e0a3-406f-8126-b306b40107f8-000000@email.amazonses.com> <3038350.4B0zn089NQ@nimes> <01000185ecf1f354-7785c91c-52c3-46f5-b2e7-7685f32c831f-000000@email.amazonses.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Received-SPF: none client-ip=81.169.146.162; envelope-from=bruno@clisp.org; helo=mo4-p00-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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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: , Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org (GalaxyMaster) wrote: > My use case in not standard since I am actually building > these into a shared library using libtool, so libtool sees the same object file > listed twice and tries to resolve it by renaming one of them and then includes > both in the resulting link command to produce a shared object. Indeed, this explains why you get a link error then. > I am building a Linux distribution from ground up. > > > - building what kind of library or binary in which way? > > I am basically building what is directly against GNU Lib's philosophy (section > 2.2 of the manual), a shared library containing every single compilable module > with all functions defined as weak symbols. ... > > I clearly understand that my use case is not something supported or endorsed by > the GNU Lib project and am not trying to change that, but it is another avenue > to test stuff, which may be valueable to the project. I have nothing against experiments. But you have to take into account that GNU gnulib (that's the actual name, not "GNU Lib") does not attempt to have backwards compatibility constraints as usual for shared libraries. This is written in the documentation https://www.gnu.org/software/gnulib/manual/html_node/Steady-Development.html and can be highlighted by a few entries of the NEWS file: getprogname The include file is changed from "getprogname.h" to . This means that source code that uses gnulib needs adaptation. scratch_buffer The function 'gl_scratch_buffer_dupfree' is removed. careadlinkat This module no longer provides the careadlinkatcwd function. A function was removed. Binaries that used this function would no longer work. diacrit This deprecated module is removed. A module with all its functions was removed. Binaries that used it would no longer work. read-file The functions provided by this module now take an 'int flags' argument to modify the file reading behavior. The read_binary_file function has been removed as it is no longer necessary. These are backward-incompatible changes on existing function names. fatal-signal The function that you pass to at_fatal_signal now takes the signal as argument. Likewise. You need to think about how you will handle these changes. Because if you don't handle these changes, you are stuck with a gnulib snapshot from 2023 for all times, and in the year 2030 it will be useless to ship seven years old code. Bruno