On Feb 23, 2013, at 12:12 PM, Alan Bateman wrote: > On 23/02/2013 18:06, Martin Buchholz wrote: >> I am actually encountering this in openjdk7 with the old build system. >> I can repro the problem in openjdk8 with the old build system, but not the >> new one. >> >> I don't know if you consider this a bug with the new build system - it's >> supposed to generate the same bits, after all???!! >> I'm not sure why - I'd guess something to do with VARIANT or FILES_m >> >> It's highly dubious whether we should have this extremely subtle and >> error-prone distinction between release and fastdebug builds at all. > Thanks for confirming it's old build only, that was my reading too but > without checking. > > Anyway, I do consider it a bug (in the old build), and really hard to track > down too until you see both libz and the JDK's libzip loaded. Kelly might > have some insight the product vs. fastdebug difference.
I have filed many issues over the years asking that mapfiles (or version scripts) be used to limit the visibility of extern symbols in Solaris and Linux. Most developers fail to understand the importance of this. I have also always wanted the fastdebug libraries and even debug build libraries to be 'plug&play' so that they exported the exact same externs and same prototypes, and could be plopped into a product build to isolate problems in just one single library. Unfortunately, some teams have added additional externs to the debug versions and that would imply the need for a different mapfile, so I suspect the easy path was to just not use a mapfile with the debug builds. It is rare that this is an issue, but obviously this is a case where it was. The policy should be that ALL shared libraries be scoped and only expose the extern symbols needed. However, with the old builds being this way all along, I see no need to go into the old builds to fix this. We have so much work to do as it is. -kto > > -Alan
