On Mon, Aug 24, 2009 at 10:17, Xueming Shen<xueming.s...@sun.com> wrote: > This is a different issue. I would prefer to separate the "to upgrade to > zlib 1.2.3" and > "to use host platform zlib on linux, if preferable" into two different > tasks. We tend to > try to put too many "similar" things into one project and end up missing the > primary > goal:-) Given the zlib is so "important", I would like to safe-land the > zlib1.2.3 first, > without touching too many other stuff.
Agreed. > Personally I agree, there is good reason to use the zlib from native > platform/resource, > "depending on your perspective", as Joe said. However there is also good > reason to > stick with the approach of "using our own zlib, even there is a native > zlib". The linux is > an open platform and zlib itself is NOT a real "standard" library like libc, > there is no > guarantee that the zlib loaded on the platform is the one you want to use. > Sure you > can do your best try to "detect"...the reason I don't want to bundle this > issue into the > upgrade work. Agreed. Using the system zlib entails binary compatibility risks of which I was not previously aware. Martin > Sherman > > Martin Buchholz wrote: >> >> It is reasonable for jni code to be built against the system zlib. >> Such jni code should not accidentally invoke the jdk bundled zlib. >> zlib includes support for symbol renaming (Z_PREFIX), >> but better is to build the jdk so that jni does not have direct access >> to the zlib functions under any name (but that might be a lot of work). >> >> Martin >> >> On Mon, Aug 24, 2009 at 00:20, Florian Weimer <fwei...@bfk.de >> <mailto:fwei...@bfk.de>> 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. >> >> -- >> Florian Weimer <fwei...@bfk.de <mailto:fwei...@bfk.de>> >> BFK edv-consulting GmbH http://www.bfk.de/ >> Kriegsstraße 100 tel: +49-721-96201-1 >> D-76133 Karlsruhe fax: +49-721-96201-99 >> >> > >
