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 678F53858D20 for ; Fri, 11 Nov 2022 13:17:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 678F53858D20 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 2ABDHAKs014971 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 11 Nov 2022 13:17:11 GMT From: Nix To: Simon Marchi via Gdb-patches Cc: "Jose E. Marchesi" , Simon Marchi , 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> Emacs: because you deserve a brk today. Date: Fri, 11 Nov 2022 13:17:09 +0000 In-Reply-To: <08a946a3-904f-0948-35af-96f77d2e008c@simark.ca> (Simon Marchi via Gdb-patches's message of "Thu, 10 Nov 2022 12:46:52 -0500") Message-ID: <87iljlwrze.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--Metrics: loom 1480; Body=7 Fuz1=7 Fuz2=7 X-Spam-Status: No, score=-1.5 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 10 Nov 2022, Simon Marchi via Gdb-patches spake thusly: > On 11/10/22 12:11, Nick Alcock via Gdb-patches wrote: >> [Tried to Cc: gdb-patches, but I'm not yet subscribed to it from this >> address. Not sure if this is going to work... and libctf is part of >> binutils anyway, so I'm Cc:ing binutils@ in so that at least my >> response goes somewhere public.] >> >> On 10 Nov 2022, Jose E. Marchesi said: >> >>>>>>>>> "Jose" == Jose E Marchesi via Gdb-patches writes: >>>> Jose> 1) The calls to AM_ZLIB and AC_ZSTD from gdb/configure.ac. >>>> Jose> 2) The definition of ZLIB and ZLIBINC from gdb/Makefile.in >>>> Jose> 3) ../config/zlib.m4 from aclocal_m4_deps in gdb/Makefile.in >>>> >>>> ... however the use in ctf-api.h seems like it would prevent removing >>>> some of the configury. gdb includes this header and so it needs the >>>> correct -I options to find the in-tree zlib.h. >>>> >>>> I don't see why ctf-api.h needs this include, but I essentially don't >>>> know anything about CTF. >>> >>> Nick, would it be possible to remove the include of zlib.h from >>> ctf-api.h? Even if libctf uses zlib, it would be good to not expose the >>> dependency in the API header... >> >> Yeah, this is an interestingly painful one. I completely agree that it >> needs fixing, because it causes problems if you don't have a system >> zlib: you end up with a basically unusable ctf-api.h after installation, >> which isn't good at all. >> >> But... this is because of this function in the exported API: >> >> extern int ctf_gzwrite (ctf_dict_t *fp, gzFile fd); > > I don't know if this is relevant, maybe this is an API that can't > change, but taking a step back, it seems strange in the first place to > leak the dependency on zlib through the API. It's historical (it was there in the Solaris days, IIRC) and alas it has users, and it has a use case (see below). We *could* rip it out and fix the users, but that does mean breaking the API and bumping soname and this seems like a rather petty reason to do so to me. (But then I know I'm a stable-API fetishist.) > Imagine you wanted to > switch to another gz compression library without changing your API. It > would be nicer if zlib was just an implementation detail here. For > instance, you could take a plain fd and use gzdopen internally to open a > gzFile around it. I think the intent here was that people who were already writing stuff through a gzFile could pass it into this to write CTF in as well. That doesn't work at all well if you pass in the underlying fd and do a gzdopen (you end up with zlib thinking there are two gzip streams underway simultaneously on the same fd, and a total mess results). So really you'd need *both* :) But really this whole class of API made more sense back in the past when zlib was the only compression library worth speaking of. These days you'd probably prefer to hand back the memory buffer and ask the caller to do the compression themselves using whatever mechanism they prefer -- but the fact remains that this thing is in the API and I'd rather not break it for such a minor reason if there is a non-totally-horrible alternative. -- NULL && (void)