From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.esperi.org.uk (icebox.esperi.org.uk [81.187.191.129]) by sourceware.org (Postfix) with ESMTPS id 4A2B4389942A for ; Mon, 14 Nov 2022 13:56:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4A2B4389942A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=esperi.org.uk Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=esperi.org.uk Received: from loom (nix@sidle.srvr.nix [192.168.14.8]) by mail.esperi.org.uk (8.16.1/8.16.1) with ESMTPS id 2AEDuTKh002453 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 14 Nov 2022 13:56:30 GMT From: Nick Alcock To: Simon Marchi Cc: Simon Marchi via Gdb-patches , "Jose E. Marchesi" , Tom Tromey , indu.bhagat@oracle.com, elena.zannoni@oracle.com, binutils@sourceware.org Subject: Re: [PATCH] gdb: use libtool in GDB_AC_CHECK_BFD References: <20221107194634.1313150-1-jose.marchesi@oracle.com> <5e940b15-cd5c-83b2-0bdd-9afa27b5f197@simark.ca> <87bkpeuae6.fsf@oracle.com> <875yfmztd6.fsf@tromey.com> <87sfiqsr7m.fsf@oracle.com> <87sfiqwx82.fsf@esperi.org.uk> <08a946a3-904f-0948-35af-96f77d2e008c@simark.ca> <87iljlwrze.fsf@esperi.org.uk> Emacs: Our Lady of Perpetual Garbage Collection Date: Mon, 14 Nov 2022 13:56:29 +0000 In-Reply-To: (Simon Marchi's message of "Fri, 11 Nov 2022 08:51:21 -0500") Message-ID: <874jv1wsfm.fsf@esperi.org.uk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-DCC-wuwien-Metrics: loom 1290; Body=7 Fuz1=7 Fuz2=7 X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP 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: On 11 Nov 2022, Simon Marchi stated: > Another idea I thought of, which would still break the API (in that > callers would need to include a new source file) but not the ABI would > be to put that declaration in a separate header, say ctf-gzip-api.h. > Users of ctf-api.h would not have to deal with zlib. Users of > ctf-gzip-api.h would have to deal with zlib, but that's fine because > they are consciously using it. This thing is distinctly rarely used, so I'd say this is the best suggestion so far: it unbreaks gdb and all known existing users can definitely adapt easily, and it avoids depending on nasty guts of zlib. If ctf-gzip-api.h #included ctf-api.h itself, the needed change to users would be even smaller. I'm trying to get a new libctf patch series into shape and can add this change to it if you like: alternatively, consider a suitable patch pre-approved. (You'll need to add a suitable #include to libctf/ctf-serialize.c.)