PING: [PATCH FOR REVIEW] System Zlib Support (original) (raw)

Kumar Srinivasan kumar.x.srinivasan at oracle.COM
Tue Aug 7 17:16:47 UTC 2012

Hi,

Please make sure that the jdk/test/tools/* tests are run and validated.

Both the java launcher and the pack200 tools are dependent on zlib entry points for inflate/deflate and other things.

Kumar

----- Original Message -----

On 08/06/2012 11:26 AM, Andrew Hughes wrote:

----- Original Message -----

Hi Andrew,

I meant if we are going to put SYSTEMZLIB=true as default for linux as Alan suggested, we might need to update the build document as well to include zlib-dev as the "necessary" package to build jdk on linux. Ok. I think that's a separate issue which warrants a separate bug& changeset. Let's have this one work on fixing the build so SYSTEMZLIB actually works on GNU/Linux first. At the moment, enabling SYSTEMZLIB=true breaks the build on anything other than MacOS/X, which seems like a bug to me. It's a separate issue. For your current patch, since it does not set the SYSTEMZLIB=true for linux, it's not an issue at all. As we override the default anyway, I'd prefer not to be the one pushing for it if it causes problems down the road :-) My apology for my naive question, is zlib (the library) always installed by default by most linux distributors? No apology required. It's not that naive a question as there are plenty of distributions out there, so giving a completely accurate answer is impossible. There's more than likely someone who doesn't :-) I would say it's extremely unlikely that the library's not installed. Looking at the dependency tree, it's a requirement of perl, nss, libpng, freetype, openssh, firefox, kdelibs& cairo to name a few. You're not going to get much of a GUI environment going without it, that's for sure. As you pointed out earlier in the thread, binary distributions tend to separate the library and the development headers / pkgconfig files. It's much less likely that zlib-devel (or whatever it gets called) is installed on a standard system, but for someone doing builds, it becomes more likely especially as it's a dependency for other development packages such as the one for libpng. Currently the SYSTEMZLIB=true is set in make/common/Defs-macosx.gmk. Ok, so it's the default there already. That explains the defines.h logic. ZLIBVERSION = 1.2.5 is setin make/common/Defs.gmk. What's the relevance of this version? My system install is 1.2.7. That's the version bundled with jdk. Yes, 1.2.7 is the latest, out May/2012. I might try to upgrade the bundled one to the latest version at later stage of jdk8. The "relevance" is that they are all used for "zlib build", so it would be better to put them together/close for future maintenance, though some comment might be necessary to clarify one is for "bundled" version, on is for the link options for os zlib. Ah, ok. So it's irrelevant if SYSTEMZLIB=true. I was worried the idea might be for the build to do a version check like it does with Freetype. That's been a pain in the past. So is the patch ok for me to push? And do we have a bug ID if so? Sorry if you've already mentioned one, but I've lost track in this thread :-) -sherman

More information about the core-libs-dev mailing list