Re: [PATCH] gdb: use libtool in GDB_AC_CHECK_BFD

[Nick Alcock <nick.alcock@oracle.com>]

[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);

Now this is actually a typedef, described as "semi-opaque":

typedef struct gzFile_s *gzFile;    /* semi-opaque gzip file descriptor */

IF the name of gzfile_s is guaranteed unchanging across zlib releases we
could do this instead of the #include:

/* Note to users: this is a 'gzFile' from <zlib.h>.  */
struct gzFile_s;
extern int ctf_gzwrite (ctf_dict_t *fp, gzFile_s *fd);

The problem is that zlib apparently considers this structure name an
implementation detail (given that what it gives you in the prototype is
a typedef to it), but if that name ever changes then including
<ctf-api.h> and <zlib.h> in the same translation unit would fail. Indeed
this function used to take a void * (with the same typedef name) in
1.2.5 and before :(

Maybe I could just make it take a void *, but that's not very clear at
all! That type name is actually useful documentation... and I can't
introduce the typedef myself because double-declaring a typedef is an
error. (And a configure test won't help here, because the problem is the
zlib version installed when *users* include <ctf-api.h>...)

So... suggestions? Do people think gzFile_s is unlikely to be renamed
again or changed away from a structure in future, so that doing this is
safe? (Even when it was a void *, it was a structure internally, albeit
a totally different one.)

-- 
NULL && (void)