Using miniz.c in multiple projects can cause symbol clashes

[GoogleCodeExporter]

miniz is designed as a single file to be included by another source file via 
#include "miniz.c" as stated in the example applications. This works fine when 
miniz is used within one project. When two projects using miniz unexpected 
results arise.

Situation:

Shared library A includes miniz.c. Application B also includes miniz.c. 
Application A will load B.


Problem:

When B loads library A there are two copies of the symbols related to miniz. 
Depending on the OS, B might fail to load A. Also, depending on the OS the 
miniz that is part of A might be used by B or vice versa. This can be a major 
issue if A and B have different versions (especially if they are not ABI or API 
compatible) of miniz included.


Solutions:

1) Make all parts within miniz.c static. This will make everything in miniz.c 
only visible to what is including it. This will prevent the miniz symbols from 
being exposed publicly.

This could be facilitated by setting a define similar to MINIZ_NO_ARCHIVE_APIS. 
Something like:

#ifdef MINIZ_STATIC
# define MINIZ_STATIC static
#else
# define MINIZ_STATIC
#endif

Then any any function that would be considered public would be prefixed by 
MINIZ_STATIC:

MINIZ_STATIC int mz_uncompress(...

2) Break miniz.c appart into miniz.h and miniz.c to facilitate building and 
installing miniz as a shared library.

Original issue reported on code.google.com by john@nachtimwald.com on 8 Aug 2012 at 3:14

[GoogleCodeExporter]

SDL2_image is one such library. When statically-compiled (eg when using 
MXE/MinGW), it usually results in link errors.

Original comment by r...@fastmail.fm on 28 Sep 2013 at 11:16

[GoogleCodeExporter]

Ok - That's a good idea, and I'll get this or something like it into the next 
release (v1.16).

Original comment by richge...@gmail.com on 13 Oct 2013 at 6:06

• Changed state: Accepted

[GoogleCodeExporter]

I ported to c/h file to avoid duplicate symbol linking errors. Not sure it is 
the best approach, but it worked in my case and you can find notes about the 
issues I ran into at 
https://github.com/mapnik/mapnik/blob/master/include/mapnik/miniz_png.hpp#L34-L4
1

Original comment by d...@mapbox.com on 14 Oct 2013 at 6:45

[GoogleCodeExporter]

+1 for separate .c/.h files. When building a library, this would allow miniz to 
inherit any library-wide build settings for symbol visibility, rather than 
defining its own. It would also work in some odd situations where including a 
.c file doesn't work (e.g. when building with qmake — 
https://bugreports.qt-project.org/browse/QTBUG-24906). Right now I'm working 
around this with `MINIZ_HEADER_FILE_ONLY`. 

Original comment by jlstrec...@gmail.com on 28 Oct 2013 at 10:30

[GoogleCodeExporter]

When you implement building a shared library, please don't forget to version 
the library properly. (E.g. the feature is called SONAME in ELF executable 
format.) Proper versioning ensures that if the library changes ABI, 
applications built against older incompatible library version get notified at 
start.

Original comment by petr.pi...@atlas.cz on 16 Oct 2014 at 2:06