8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Mon Apr 9 11:29:25 UTC 2018
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 ZIP_CRC32 to zip_util.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 @@
> DISABLED_WARNINGS_gcc := implicit-fallthrough, \
> LDFLAGS := $(LDFLAGS_JDKLIB) \
> $(call SET_SHARED_LIBRARY_ORIGIN), \
> + LDFLAGS_windows := -export:ZIP_Open -export:ZIP_Close -export:ZIP_FindEntry \
> + -export:ZIP_ReadEntry -export:ZIP_GetNextEntry \
> + -export:ZIP_InflateFully -export:ZIP_CRC32 -export:ZIP_FreeEntry, \
> LIBS_unix := -ljvm -ljava $(LIBZ_LIBS), \
> LIBS_windows := jvm.lib $(WIN_JAVA_LIB), \
> ))
> @@ -221,6 +224,10 @@
> CFLAGS_unix := -UDEBUG, \
> LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \
> $(call SET_SHARED_LIBRARY_ORIGIN), \
> + LDFLAGS_windows := -export:JIMAGE_Open -export:JIMAGE_Close \
> + -export:JIMAGE_PackageToModule \
> + -export:JIMAGE_FindResource -export:JIMAGE_GetResource \
> + -export:JIMAGE_ResourceIterator -export:JIMAGE_ResourcePath, \
> LIBS_unix := -ljvm -ldl $(LIBCXX), \
> LIBS_macosx := -lc++, \
> LIBS_windows := 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, ZIP_CRC32 is exported as _ZIP_CRC32 at 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.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/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.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/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.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/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
>>>>
>
More information about the build-dev
mailing list