Re: [PATCH] gdb: use libtool in GDB_AC_CHECK_BFD

[Simon Marchi <simark@simark.ca>]

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.  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.

Simon