Kelly, Thanks. I think we agree. I think we have consensus that my change is an improvement and should be committed. Can I haz approval?
I'm not brave enough to try to change the default for all mapfiles, although I would support Kelly or anyone else who tries. Martin On Mon, Feb 25, 2013 at 9:18 AM, Kelly O'Hair <kelly.oh...@oracle.com>wrote: > > 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 > >
