Define JNIEXPORT as visibility default with GCC? (original) (raw)

Martin Buchholz martinrb at google.com
Thu Feb 14 01:14:40 UTC 2013

This seems like an obvious improvement. There are already bunches of places in the jdk sources that do things like:

./hotspot/src/cpu/x86/vm/jni_x86.h #if defined(SOLARIS) || defined(LINUX) || defined(_ALLBSD_SOURCE)

#if defined(GNUC) && (GNUC > 4) || (GNUC == 4) && (GNUC_MINOR > 2) #define JNIEXPORT attribute((visibility("default"))) #define JNIIMPORT attribute((visibility("default"))) #else #define JNIEXPORT #define JNIIMPORT #endif

This is crazy. The visibility feature has nothing to do with x86, or SOLARIS, or LINUX, or BSD. JNIEXPORT should be defined to attribute((visibility("default"))) #if #and #only #if: defined(GNUC) && (GNUC > 4) || (GNUC == 4) && (GNUC_MINOR > 2)

and that change should simply be made to the public exported jdk jni headers

Martin

On Mon, Feb 11, 2013 at 10:26 AM, Jeremy Manson <jeremymanson at google.com>wrote:

Hi folks,

Pardon if this has come up before; a quick search didn't indicate anything, but the mailing list archives are kind of hard to search. I wonder if it makes sense to define JNIEXPORT as meaning attribute ((visibility ("default"))) when compiling with gcc. Currently, anyone building JNI code with -fvisibility=hidden and a stock Oracle JDK is at a loss: their JNI exports will be hidden along with everything else. I notice that both IcedTea and OS X have made this change independently, and it has been added to Hotspot's JNIEXPORT definition (so HS can be built with -fvisibility=hidden), but the change isn't present in the latest JDK8 bits:

http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/933742f4bb4c/src/solaris/javavm/export/jnimd.h The workaround is pretty ugly: people who want to use -fvisibility=hidden have to redefine JNIEXPORT. Upstream, it would be a pretty simple change to jnimd.h, along the lines of: #if defined(GNUC) && GNUC >= 4 #define JNIEXPORT attribute ((visibility ("default"))) #else #define JNIEXPORT #endif Any thoughts? Jeremy

More information about the core-libs-dev mailing list