madler
Fix and extend Z_PREFIX support
There are 2 commits here: the first one is trivial and, hopefully, uncontroversial and really should be applied because without it Z_PREFIX doesn't really work as intended as the library built without and with it still clash at link-time due to duplicate z_errmsg definitions. Renaming this symbol to (ugly, but who cares, it's internal anyhow) z_z_errmsg allows to avoid this.
The second commit is more extensive, but still conceptually simple: it allows predefining Z_PREFIX_ when building the library to use a more unique prefix than z_. I think it's a nice addition because it allows to build completely customized versions of the library that are certain not to clash with anything else. The main problem I see with this change is the hack for the functions that are redefined as macros when Z_WANTS64. I realize it's not pretty and not very maintainable, but I just couldn't find any other way of doing this.
It doesn't seem like the PRs in this repository are monitored at all but, just in case it can be useful to somebody else, I've updated this PR to also add prefixes to the new crc32_combine_xxx functions added in 1.2.12, as zconf.h wasn't updated at all after adding them.
Of course, if any of the maintainers could look at this PR, it still would be great, even half a decade after its submission...
@vadz It's a nice fix.
BTW, a small question, why not add command option to configure?
It would be simple enough to add a configure option, of course, but I'd rather see this PR accepted first before doing any more changes. Admittedly, this seems pretty unlikely to happen after ~4.5 years but who knows...