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 [email protected] on 8 Aug 2012 at 3:14