if the symbols weren't part of the public API in the first place, this doesn't mean the SONAME needs to be bumped. i.e. if people are doing things like "extern safeboolean empty_output_buffer(j_compress_ptr cinfo);" and then calling that func, that is their problem, not ours.
here's the funcs that have been deleted and are not listed in the headers (and thus do not require the SONAME to be updated):
that isn't irresponsible at all. the ABI isn't defined by accidental symbol exports, it's defined by the API we say it is. people using obviously internal symbols are violating the API which means they deserve to break. otherwise, you're basically saying that if we have a compiler that lacks symbol visibility (which configure checks for) then we need to bump the SONAME pretty much every release because a new internal func is added/removed/changed. that is an unreasonable position that no other project takes, and bumping the SONAME like this is irresponsible on our part. library authors have a duty to keep the SONAME stable whenever possible.
in sampling the projects that i happen to have installed on my system that use GD, i don't see any of them using gdcache.h or gd_io.h, or the funcs defined therein.
php-5.4.x and older do search for gdCacheCreate (that configure logic is weird) and uses it to control whether to build its local copy of caching code. not sure whether this will break the build, but they've dropped the logic with php-5.5.x.
note that the struct gdIOCtx in gd_io.h is still needed. that's how people use the funcs that end in "Ctx".
googling for the headers and some of the funcs therein only shows gd itself. so i guess we can try deleting the headers and see if anyone complains.
Mike, you have a very good point here. gdIOCtx is required. However we do not expose the other functions declared there, not necessary. What's about moving this struct declaration to gd.h and make it public?
About relying on compiler features to make something public or not, that's partially the case. Basically the main idea is to have headers with only what could be used. The same should be about the members of a struct (APIs should be used to access them) but that's not possible to restrict that, so we should clearly document the how and why.
moving the gdIOCtx to gd.h seems like the easiest route to dropping the gd_io.h header
for structs, you can make them entirely opaque, or just certain fields. this can be accomplished a few different ways, but the easiest is probably via just some ifdefs. you can even remove the struct entirely from visibility by replacing it with alloc/free/get/set helpers. not saying we need to go that far, just that it's possible. as you say, what exactly we expect to be part of the API in the struct should be documented. certainly the size/layout of the struct is part of the ABI today.
on a related note, i see that we're using HAVE_xxx defines in gd.h. that doesn't work. we should do:
and unconditionally define USE_VISIBILITY to 0 or 1.