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 
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 */
main(int argc, char **argv)
     int margc;

  1.  Zip-library  has runtime issues   when  symbols  are resolved  in  

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 @@
ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong outLen, char 

+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 :


change :


mostly I added  JNIEXPORT / JNICALL at some places  where  the win32bit build 
missed it .

A difference is  
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 
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 

That's most likely a result of the new JNIEXPORT I added as part of the mapfile 

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. :)


5 apr. 2018 kl. 17:20 skrev Baesken, Matthias 
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 :

 : error C2373: 'j2d_mlib_ImageConvKernelConvert' : redefinition; different 
type modifiers
 : 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 
+++ 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* 
         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

Reply via email to