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, ZIP_CRC32 is exported as _ZIP_CRC32@12, and classLoader.cpp cannot find the function.


I think adding prototype of ZIP_CRC32 to zip_util.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.baes...@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/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;
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>
Cc: build-dev@openjdk.java.net; Doerr, Martin <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>:

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/mlib_ImageConvKernelConvert.c(87) : error C2373: 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type modifiers
         
e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\mlib_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

Reply via email to