Re: [PATCH] gdb: use libtool in GDB_AC_CHECK_BFD

[Nix <nix@esperi.org.uk>]

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 <gdb-patches@sourceware.org> 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)