8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT (original) (raw)

Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Mon Apr 9 11:42:23 UTC 2018

Those were added by my patch that removed the map files.

/Magnus

9 apr. 2018 kl. 13:38 skrev Baesken, Matthias <matthias.baesken at sap.com>:

I did not add JNICALL decorations to any libzip functions , please see my webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/

, the problem here is the added JNICALL decoration, which affects only win32 (and incorrectly, that is). so I wonder which added JNICALL decoration you are refering to . Best regards, Matthias

-----Original Message----- From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] Sent: Montag, 9. April 2018 13:29 To: Baesken, Matthias <matthias.baesken at sap.com> Cc: Alexey Ivanov <alexey.ivanov at oracle.com>; build-dev <build-_ _dev at openjdk.java.net>; Doerr, Martin <martin.doerr at sap.com> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations Reinstating the -export command line options is not the way forward here. As I understood it from private conversation with Alexey, the problem here is the added JNICALL decoration, which affects only win32 (and incorrectly, that is). /Magnus 9 apr. 2018 kl. 12:46 skrev Baesken, Matthias <matthias.baesken at sap.com>:

I think adding prototype of ZIPCRC32 to ziputil.h is unnecessary as this function is correctly decorated in CRC32.c and is exported. Hi Alexey, you are correct on this one . The added declaration does not help with the "Corrupted ZIP library" error . This one can be fixed by bringing back the exports in the makefile make/lib/CoreLibraries.gmk (same for some JIMAGE functions) : --- a/make/lib/CoreLibraries.gmk Sun Apr 08 17:01:20 2018 +0800 +++ b/make/lib/CoreLibraries.gmk Mon Apr 09 12:44:08 2018 +0200 @@ -191,6 +191,9 @@ _DISABLEDWARNINGSgcc := implicit-fallthrough, _ _LDFLAGS := $(LDFLAGSJDKLIB) _ _$(call SETSHAREDLIBRARYORIGIN), _ + LDFLAGSwindows := -export:ZIPOpen -export:ZIPClose - _export:ZIPFindEntry _ _+ -export:ZIPReadEntry -export:ZIPGetNextEntry _ _+ -export:ZIPInflateFully -export:ZIPCRC32 -export:ZIPFreeEntry, _ _LIBSunix := -ljvm -ljava $(LIBZLIBS), _ _LIBSwindows := jvm.lib $(WINJAVALIB), _ )) @@ -221,6 +224,10 @@ _CFLAGSunix := -UDEBUG, _ _LDFLAGS := (LDFLAGSJDKLIB)(LDFLAGSJDKLIB) (LDFLAGSJDKLIB)(LDFLAGSCXXJDK) _ _$(call SETSHAREDLIBRARYORIGIN), _ _+ LDFLAGSwindows := -export:JIMAGEOpen -export:JIMAGEClose _ _+ -export:JIMAGEPackageToModule _ _+ -export:JIMAGEFindResource -export:JIMAGEGetResource _ _+ -export:JIMAGEResourceIterator -export:JIMAGEResourcePath, _ _LIBSunix := -ljvm -ldl $(LIBCXX), _ _LIBSmacosx := -lc++, _ _LIBSwindows := jvm.lib, _ I wonder why the 64bit windows build can live without the exports , any ideas ? Best regards , Matthias -----Original Message----- From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] Sent: Samstag, 7. April 2018 00:14 To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Baesken, Matthias <matthias.baesken at sap.com> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin <martin.doerr at sap.com> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations Hi Magnus, Matthias, I tried to build 32 bit Windows but it fails to run for me with Corrupted ZIP library: c:\work\jdk-dev\build\windows-x86-normal-server- release\jdk\bin\zip.dll The problem is that zip.dll exports all symbols as C++ rather than C. For example, ZIPCRC32 is exported as ZIPCRC32 at 12, and classLoader.cpp cannot find the function.

I think adding prototype of ZIPCRC32 to ziputil.h is unnecessary as this function is correctly decorated in CRC32.c and is exported. Regards, Alexey On 06/04/2018 17:33, Magnus Ihse Bursie wrote: I think it's reasonable to update the existing webrev. /Magnus 6 apr. 2018 kl. 15:20 skrev Baesken, Matthias <matthias.baesken at sap.com>: Hello, I just noticed 2 additonal issues regarding mapfile-removal : The follow up change that removed mapfiles for exes as well leads on Win32 bit to this link error : Creating library C:/JVM/jdkjdkntintel/support/native/java.base/java/java.lib and object C:/JVM/jdkjdkntintel/support/native/java.base/java/java.exp LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol main _referenced in function tmainCRTStartup C:/JVM/jdkjdkntintel/support/native/java.base/javaobjs/java.exe : fatal error LNK1120: 1 unresolved externals

Looks like we cannot have JNICALL in main.c : diff -r 4f6887eade94 src/java.base/share/native/launcher/main.c --- a/src/java.base/share/native/launcher/main.c Thu Apr 05 14:39:04 2018 -0700 +++ b/src/java.base/share/native/launcher/main.c Fri Apr 06 15:16:40 2018 +0200 @@ -93,7 +93,7 @@ _initenv = environ; #else /* JAVAW */ -JNIEXPORT int JNICALL +JNIEXPORT int main(int argc, char **argv) { int margc; Zip-library has runtime issues when symbols are resolved in src/hotspot/share/classfile/classLoader.cpp. I added the declaration of the missing symbol, this seems to fix it . diff -r 4f6887eade94 src/java.base/share/native/libzip/ziputil.h --- a/src/java.base/share/native/libzip/ziputil.h Thu Apr 05 14:39:04 2018 -0700 +++ b/src/java.base/share/native/libzip/ziputil.h Fri Apr 06 15:16:40 2018 +0200 @@ -284,4 +284,7 @@ JNIEXPORT jboolean JNICALL ZIPInflateFully(void *inBuf, jlong inLen, void *outBuf, jlong outLen, char **pmsg); +JNIEXPORT jint JNICALL +ZIPCRC32(jint crc, const jbyte *buf, jint len); + Should I prepare another bug, or add this to the existing one and post a second webrev ? Best regards, Matthias From: Baesken, Matthias Sent: Freitag, 6. April 2018 09:54 To: 'Magnus Ihse Bursie' <magnus.ihse.bursie at oracle.com> Cc: build-dev at openjdk.java.net; Doerr, Martin <martin.doerr at sap.com> Subject: RFR: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations Hello, please review : Bug : https://bugs.openjdk.java.net/browse/JDK-8201226 change : http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/ mostly I added JNIEXPORT / JNICALL at some places where the win32bit build missed it . A difference is src/java.desktop/share/native/libsplashscreen/splashscreenimpl.h Where I removed a few declarations (one decl with one without JNIEXPORT / JNICALL – looked a bit strange ) . Best regards , Matthias From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] Sent: Donnerstag, 5. April 2018 17:45 To: Baesken, Matthias <matthias.baesken at sap.com> Cc: build-dev at openjdk.java.net; Doerr, Martin <martin.doerr at sap.com> Subject: Re: missing JNIEXPORT / JNICALL at some places in function declarations/implementations That's most likely a result of the new JNIEXPORT I added as part of the mapfile removal. I tried to match header file and C file, but I can certainly have missed cases. If I didn't get any warnings, it was hard to know what I missed. Please do submit your patch. I'm a bit surprised 32-bit Window is still buildable. :) /Magnus 5 apr. 2018 kl. 17:20 skrev Baesken, Matthias <matthias.baesken at sap.com>: Hello, we noticed that at a number of places in the coding , the JNIEXPORT and/or JNICALL modifiers do not match when one compares the declaration and The implementation of functions. While this is ok on most platforms, it seems to fail on Windows 32 bit and leads to errors like this one : e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlibimage/ml ibImageConvKernelConvert.c(87) : error C2373: 'j2dmlibImageConvKernelConvert' : redefinition; different type modifiers e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlibimage\ml ibimageproto.h(2630) : see declaration of 'j2dmlibImageConvKernelConvert' (there are quite a few of these e.g. in mlib / splashscreen etc.) Another example is this one : diff -r 4d98473ed33e src/java.base/share/native/libjimage/jimage.hpp --- a/src/java.base/share/native/libjimage/jimage.hpp Thu Apr 05 09:55:16 2018 +0200 +++ b/src/java.base/share/native/libjimage/jimage.hpp Thu Apr 05 17:07:40 2018 +0200 @@ -126,7 +126,7 @@ * JImageLocationRef location = (*JImageFindResource)(image, * "java.base", "9.0", "java/lang/String.class", &size); */ -extern "C" JNIEXPORT JImageLocationRef JIMAGEFindResource(JImageFile* jimage, +extern "C" JNIEXPORT JImageLocationRef JNICALL JIMAGEFindResource(JImageFile* jimage, const char* modulename, const char* version, const char* name, jlong* size); Is there some generic way to get the same declarations / impementations in the code ? Or should I just add a patch with my findings ? Best regards, Matthias

More information about the build-dev mailing list