Do not let internal JDK zlib symbols leak out of fastdebug libzip.so
martinrb at google.com
Mon Feb 25 21:27:30 UTC 2013
Thanks. I think we agree.
I think we have consensus that my change is an improvement and should be
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.
On Mon, Feb 25, 2013 at 9:18 AM, Kelly O'Hair <kelly.ohair at 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.
> > -Alan
More information about the core-libs-dev