On Mon, Aug 24, 2009 at 11:06, Xueming Shen<xueming.s...@sun.com> wrote: > Florian Weimer wrote: >> >> * Martin Buchholz: >> >> >>> >>> 45 +#ifdef _LP64 >>> 46 +typedef unsigned int uLong; /* 32 bits or more */ >>> 47 +#else >>> 48 typedef unsigned long uLong; /* 32 bits or more */ >>> 49 +#endif >>> >> >> This is guaranteed to break interoperability with the system zlib. If >> you want to make such adjustments, you really have to rename all >> functions to avoid name clashes. Such clashes materialize if you load >> a DSO which contains code linked to the system zlib (usually via JNI). >> >> Technically, this is not a regression because OpenJDK's existing zlib >> 1.1 code is incompatible with 1.2 zlibs used on most systems, so the >> same problem happens. >> >> > > None of the zlib functions/methods is exported from libzip.o as "glocal" > symbol, we are using > make/java/zip/mapfile_vers to make them "local". Those zlib methods are > supposed to be > only accessed by our "own" jar/zip jnis. So what is exactly the > "interoperability with the system > zlib" concern here? >
Sherman: Running "nm" on jdk7 binaries suggests that you are right. Florian: Do you have a test case demonstrating zlib failure due to namespace contamination? Martin
