Re: [Mingw-w64-public] MSYS2 dlltool finds no symbols in Oracle jvm.dll, is that to be expected?

2016-08-19 Thread Mario Emmenlauer 

Thanks! Indeed, using gendef works and I get a lot of exports
from the dll! I also checked dlltool from mingw-w64 and it does
not export anything, so gendef seems to be the way to go!
Thanks again!




On 19.08.2016 20:32, The Canadian Bacon wrote:
> I'm not an msys2 dev but have you tried running the tool gendef on the DLL
> itself and see what's there? Should be in the mingw tools package.
> 
> On Aug 19, 2016 2:01 PM, "Mario Emmenlauer"  wrote:
> 
>>
>> Dear MinGW-w64 developers,
>>
>> I'm using MSYS2 dlltool on a dll from Oracle Java 1.8 x64: jvm.dll.
>> Using dlltool finds no symbols. I reported this to MSYS2 team, and
>> got a very quick response from David Macek: It seems `nm` and
>> `dlltool` don't recognize exports in non-mingw libraries. `objdump`
>> recognizes it.
>>
>> Could you please help me (and the MSYS2 team) by clarifying if this
>> is expected behavior or a known bug, or if the fault lies in the MSYS2
>> builds?
>>
>> Below my original report, for your reference.
>>
>> Thanks a lot and all the best,
>>
>> Mario
>>
>>
>>
>> 
>>
>> I need to compile a Python 2 extension called 'javabridge' that
>> links against the Oracle JVM. The compile fails with undefined
>> symbols:
>>
>> C:\msys2\mingw64\bin/x86_64-w64-mingw32-gcc.exe -shared
>> -Wl,--enable-auto-image-base -pipe -s -s build/temp.mingw-2.7/_
>> javabridge.o
>> build/temp.mingw-2.7/_javabridge_nomac.o build/temp.mingw-2.7/_
>> javabridge.def
>> -Lc:/users/emmenlau/appdata/local/temp/pip-build-rnax5q/javabridge
>> "-LC:\Program
>> Files\Java\jdk1.8.0_101/lib" -LC:/msys2/mingw64/lib/python2.7/config
>> -LC:/msys2/mingw64/lib -ljvm -lpython2.7 -o
>> build/lib.mingw-2.7/javabridge/_javabridge.pyd
>>
>> build/temp.mingw-2.7/_javabridge.o:_javabridge.c:(.text+0xda3):
>> undefined
>> reference to `__imp_StopVM'
>>
>> build/temp.mingw-2.7/_javabridge.o:_javabridge.c:(.text+0x1f4aa):
>> undefined
>> reference to `__imp_CreateJavaVM'
>>
>> build/temp.mingw-2.7/_javabridge_nomac.o:_javabridge_nomac.c:(.text+
>> 0x103):
>> undefined reference to `__imp_JNI_CreateJavaVM'
>>
>> collect2.exe: error: ld returned 1 exit status
>>
>> error: command 'C:\\msys2\\mingw64\\bin/x86_64-w64-mingw32-gcc.exe'
>> failed
>> with exit status 1
>>
>>
>> I want to debug the issue and check that the def-file is correct.
>> So I try to run dlltool on jvm.dll, but it says "no symbols". How
>> does that make sense? Its the official Oracle Java JVM 1.8.0_101,
>> the dll must have symbols? Here is what I tried:
>>
>> #> dlltool -z /tmp/somedll.def --export-all-symbol '/c/Program
>> Files/Java/jdk1.8.0_101/jre/bin/server/jvm.dll'
>>
>> C:\msys2\mingw64\bin\dlltool.exe: C:/Program
>> Files/Java/jdk1.8.0_101/jre/bin/server/jvm.dll: no symbols
>>
>> Indeed the generated def-file has only a header, no symbols.
>> Can you please suggest what I'm doing wrong? I'm on the mingw64
>> MSYS2 shell and its 64bit Java.
>>
>> Thanks a lot,
>>
>> Mario



--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] _CRTIMP

2016-08-19 Thread David Wohlferd 
My next patch is very small, but it affects a bunch of code.  Ponder it 
a bit before approving.  The goal is to fix all the warnings like this:


 warning: '_unlock_file' redeclared without dllimport attribute: 
previous dllimport ignored [-Wattributes]


This occurs because our headers use:

  _CRTIMP void __cdecl _unlock_file(FILE *_File);

and _CRTIMP is always defined like this:

#ifndef _CRTIMP
#define _CRTIMP __declspec(dllimport)
#endif

If we were *only* providing a mapping to the function in a DLL, this 
would be fine.  But we actually create an implementation of this 
function (mingw-w64-crt/stdio/mingw_lock.c).  And the implementation 
uses the same header.  Since it makes no sense to have an implementation 
tagged as dllimport, I assert that when building mingw-w64, _CRTIMP 
should always be defined as blank (attached).


dw
diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 886fcf0..e52f961 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -20,7 +20,7 @@ else
 endif
 
 AM_CPPFLAGS=-D_CRTBLD $(sysincludes)
-AM_CFLAGS=-pipe -std=gnu99 -D_WIN32_WINNT=0x0f00 @ADD_C_CXX_WARNING_FLAGS@ @ADD_C_ONLY_WARNING_FLAGS@
+AM_CFLAGS=-pipe -std=gnu99 -D_WIN32_WINNT=0x0f00 @ADD_C_CXX_WARNING_FLAGS@ @ADD_C_ONLY_WARNING_FLAGS@ -D_CRTIMP=
 AM_CXXFLAGS=@ADD_C_CXX_WARNING_FLAGS@ @ADD_CXX_ONLY_WARNING_FLAGS@
 CPPFLAGSARM32=-mfpu=vfp
 CPPFLAGS32=-m32
diff --git a/mingw-w64-crt/Makefile.in b/mingw-w64-crt/Makefile.in
index 58c05c2..746d246 100644
--- a/mingw-w64-crt/Makefile.in
+++ b/mingw-w64-crt/Makefile.in
@@ -5092,7 +5092,7 @@ top_srcdir = @top_srcdir@
 @WITHSYSROOT_FALSE@withsys = 
 @WITHSYSROOT_TRUE@withsys = --with-sysroot=@TARGET_SYSTEM_ROOT@
 AM_CPPFLAGS = -D_CRTBLD $(sysincludes)
-AM_CFLAGS = -pipe -std=gnu99 -D_WIN32_WINNT=0x0f00 @ADD_C_CXX_WARNING_FLAGS@ @ADD_C_ONLY_WARNING_FLAGS@
+AM_CFLAGS = -pipe -std=gnu99 -D_WIN32_WINNT=0x0f00 @ADD_C_CXX_WARNING_FLAGS@ @ADD_C_ONLY_WARNING_FLAGS@ -D_CRTIMP=
 AM_CXXFLAGS = @ADD_C_CXX_WARNING_FLAGS@ @ADD_CXX_ONLY_WARNING_FLAGS@
 CPPFLAGSARM32 = -mfpu=vfp
 CPPFLAGS32 = -m32
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public