Re: [PATCH] gdb: use libtool in GDB_AC_CHECK_BFD

[Simon Marchi <simark@simark.ca>]

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

Thanks for the details.

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.

Simon