-----Original Message-----
From: Alan Bateman [mailto:alan.bate...@oracle.com]
Sent: Donnerstag, 12. April 2018 12:54
To: Baesken, Matthias <matthias.baes...@sap.com>; Magnus Ihse Bursie
<magnus.ihse.bur...@oracle.com>
Cc: build-dev@openjdk.java.net; Doerr, Martin <martin.do...@sap.com>;
core-libs-...@openjdk.java.net
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
Adding core-libs-dev as this is change code in libjava, libzip,
libjimage, ...
Can you confirm that this is the up to date webrev:
http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/
As I read it, this changes the calling convention of these functions on
32-bit Windows but it will have no impact on 64-bit Windows (as
__stdcall is ignored) or other platforms, is that correct?
-Alan
On 06/04/2018 14:20, Baesken, Matthias wrote:
Hello, I just noticed 2 additonal issues regarding mapfile-removal :
1. The follow up change that removed mapfiles for exes as well
leads on Win32 bit to this link error :
Creating library
C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and object
C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp
LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main
referenced in function ___tmainCRTStartup
C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/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;
1. 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/zip_util.h
--- a/src/java.base/share/native/libzip/zip_util.h Thu Apr 05 14:39:04
2018 -0700
+++ b/src/java.base/share/native/libzip/zip_util.h Fri Apr 06 15:16:40
2018 +0200
@@ -284,4 +284,7 @@
JNIEXPORT jboolean JNICALL
ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong outLen, char
**pmsg);
+JNIEXPORT jint JNICALL
+ZIP_CRC32(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.bur...@oracle.com>
Cc: build-dev@openjdk.java.net; Doerr, Martin <martin.do...@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/splashscreen_impl.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.bur...@oracle.com]
Sent: Donnerstag, 5. April 2018 17:45
To: Baesken, Matthias
<matthias.baes...@sap.com<mailto:matthias.baes...@sap.com>>
Cc: build-dev@openjdk.java.net<mailto:build-dev@openjdk.java.net>;
Doerr, Martin <martin.do...@sap.com<mailto:martin.do...@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.baes...@sap.com<mailto:matthias.baes...@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/libmlib_image/ml
ib_ImageConvKernelConvert.c(87) : error C2373:
'j2d_mlib_ImageConvKernelConvert' : redefinition; different type modifiers
e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\ml
ib_image_proto.h(2630) : see declaration of
'j2d_mlib_ImageConvKernelConvert'
(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
JIMAGE_FindResource(JImageFile* jimage,
+extern "C" JNIEXPORT JImageLocationRef JNICALL
JIMAGE_FindResource(JImageFile* jimage,
const char* module_name, 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
