On 5/7/13 10:55 AM, David DeHaven wrote:
We just discovered that every symbol is libjvm is being exported on OSX. The
OSX/BSD makefiles were copied from the linux ones and so have the options for
linker scripts and mapfiles, but as OSX doesn't support linker scripts this is
disabled by setting LDNOMAP=true - hence all symbols are exported.
However the OSX linker does support -exported_symbols_list
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/ld.1.html
so I was wondering why the build wasn't modified to use that so that we only
export the JVM symbols we intend to export? (That's a question for the
macosx-port-dev folk :) ).
Does anyone have experience using this such that we can get the hotspot build
fixed?
Exports should be handled by the visibility settings. Until recently the JNIEXPORT macro resolved to
nothing, now it sets __attribute__(("visibility" ("default))) (at least in 8, that should
be backported to 7u if it hasn't already). The "default" visibility means export that symbol.
To hide non-exported symbols you need to provide --fvisibility=hidden to gcc or clang when compiling.
Hotspot has it's own jni_md.h headers with macros to determine JNIEXPORT, but
they were wrong last I checked. It appears they attempted to clear the macro if
a certain version of gcc was used, but what happens is it disables it for all
versions of gcc above a particular release (which hasn't been used on Mac is
quite some time). I pointed this out when the JNIEXPORT patch was posted for
review to core-libs-dev (I think...), it was CC'd to the hotspot list too so
someone has to have seen it. I'm not sure if it's been fixed or not.
-DrD-
The HotSpot fix is being reviewed on [email protected]
under the following subject line:
Review request for JDK-8009729: Refix hotspot jni_<cpu>.h JNIEXPORT and
JNIIMPORT definitions to match jdk version
Dan
