From: manu0507 <E.F...@op...> - 2011-12-13 01:57:48
|
Hello, I have a perfectly running MinGW32 on a XP-32 machine, and a perfectly running MinGW64 on a Win7-64 machine - brilliant work, guys! In order to build 32-bit versions of my projects on the Win7-64 machine, I also installed a recent version of MinGW32 on the Win7-64, using mingw-get-inst-20111118.exe - everything's perfect, including pthreads etc. (once again: great job!). But now I need to access Java windows in JNI, and to do so I need to link with jawt.dll supplied in Java's jdk. With MinGW64, this became trivial once I learned on a forum that simply adding -Wl,"$(JAVA_HOME)"/jre/bin/jawt.dll to the parameters given to dllwrap does the whole trick (stunning, btw!). Unfortunately, the same does not seem to work with MinGW32 (too bad!), so I did the "standard" stuff of creating an interface static library (.a) and linking with that instead. I did that by creating the following .def file with pexports: LIBRARY jawt.dll EXPORTS _JAWT_GetAWT@8 and creating libjawt.dll.a with dlltool: dlltool --no-leading-underscore -l libjawt.dll.a -d jawt.dll.def -D [the path to]jawt.dll Finally, simply adding -ljawt.dll to dllwrap's parameters does the trick with MinGW32 on XP-32: libjawt.dll.a is linked with the rest of the project (thus resolving the _imp__JAWT_GetAWT@8 symbol), yielding a perfectly running 32-bit image (a DLL, actually). But building the 32-bit version of the project exactly the same way (using the same libjawt.dll.a) using MinGW32 on the Win7-64 machine does NOT work. Here's what I'm getting: dllwrap -static --output-def olepmgcc.def --driver-name c++ --export-all-symbols --add-stdcall-alias -mthreads -O3 -o Oljv2exe.dll [.o files] -lpthread.dll -mwindows -lwsock32 -lole32 -L./. -ljawt.dll dllwrap: no export definition file provided. Creating one, but that may not be what you want Oljv2exe.exp: file not recognized: File format not recognized collect2: ld returned 1 exit status dllwrap: c++ exited with status 1 mingw32-make: *** [Oljv2exe.dll] Error 1 Needless to say, there is no Oljv2exe.exp anywhere prior to the build, i.e. the faulty Oljv2exe.exp is generated by the compiler/linker itself... Any idea on how to solve this would be greatly appreciated! Many thanks, Emanuel -- View this message in context: http://old.nabble.com/Link-with-32-bit-DLL-ok-on-XP-32-but-fails-on-Win7-64-tp32962110p32962110.html Sent from the MinGW - User mailing list archive at Nabble.com. |
From: Ralph E. <ral...@gm...> - 2011-12-13 15:02:09
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Make sure the dll you try linking to is actually a 32 bit dll if linking with the 32 bit mingw you cannot link 64 bit dll's with 32 bit stuff and vice versa (atleast not in any working fascion). A good way to check if the dll is the right type is downloading dependency walker from here http://www.dependencywalker.com/ and open the dll with it. It will tell you exactly what type of dll you have. Hope this helps. Ralph -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO52jmAAoJEIjGvG7Y4HU8tqIH/1ngl8u/g8wafMxKfRra6uIk u2oCt08DG0kIVFObBgMFfn5ZfcYpvk2E12PiUa/+4NTvD8RbsE2HoUUlBj/V2ohd 9FpYcicaEg5No72BtBYka6ufkRiJTIrI2VBfNLte9NIgIPbAEpYfKWdAe1tvhxqh 8cBp/fSigj5mcHB0R8bkqelBq1dutJ7Zbe2DDG/8OaAgC2n5WY4mQLoAVzacnnsr NxdIwM4v8k1kMq1owKoENCqbTswvn9WwFeNnVW3e7TzgMZ+VpWXCGS18Ap8YdWRX 2kRBrRs1XoDc1/ige7IpFeAPiVmRTG+QwNrPTq84iQgIZyVNvoOUVMnWA/Snjbo= =m5KE -----END PGP SIGNATURE----- |
From: manu0507 <E.F...@op...> - 2011-12-14 03:20:42
|
Ralph, Ralph Engels wrote: > > Make sure the dll you try linking to is actually a 32 bit [...] A good way > to check if the dll is the right type is downloading dependency walker > from here http://www.dependencywalker.com/ and open the dll with it. [...] > > Ralph > Absolutely BRILLIANT, thank you! Of course I know you cannot mix 32 and 64 bits in the same image, and my DLL is indeed a 32 bit... at least I thought so... Using which together with depends, I realized that dllwrap actually kept trying to link with another copy of jawt.dll, namely the "default" one... which is 64-bit on a Win7-64 machine. For those faced with a similar problem, this is what solved it. Most of the time, you indeed want to have the 64-bit version of the DLL accessible, so modifying the system Path variable would spoil your system most of the time. Fortunately, mingw32-make makes it possible to issue PATH := D:\Programs\MinGW\bin;$(PATH) to prepend the path to the 32-bit DLL just for the duration of the build (kudos, btw!). Problem solved, the build is flawless. Thanks again (five stars coming!) Emanuel -- View this message in context: http://old.nabble.com/Link-with-32-bit-DLL-ok-on-XP-32-but-fails-on-Win7-64-tp32962110p32972307.html Sent from the MinGW - User mailing list archive at Nabble.com. |
From: Ralph E. <ral...@gm...> - 2011-12-14 06:52:26
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Np m8 :) glad i could help. And merry cristmas. Ralph -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO6EegAAoJEIjGvG7Y4HU8g9AH/iRZsotIoj5MSAccBq3zmCvS QhmkRLTrlD9qBjbUV+HbD4iSAdQ/SiSJz4HbBmUBNLtcvqBxT5yia7RFTM9rF+SP wfioWADhpG1qPSJQG2DKPrJPkEcf8xaVP0hD1dmxNCn7zJLdzHAGSTowvatYLtd3 /81WDoMwTLyRLXPrWcLhVSHq6XQn2sct1zZVC4KRbKD/RlshkaKFkdaCPsZ7Rj9t D82AHUK+k9qJtMCzQfFMjo1idGWHRZRvZ88Ts9LJATWJ/gnto8D24Fo07/EkGNn6 vYUzziPY4KWOWF/R5coVnSAvPrISgONMVeircMzKUSs6tzdjRQgk0BblzsAp4JQ= =cDrd -----END PGP SIGNATURE----- |
From: Fabian G. <fa...@gr...> - 2011-12-14 08:08:39
|
Am 14.12.2011 04:20, schrieb manu0507: > system most of the time. Fortunately, mingw32-make makes it possible > to issue > PATH := D:\Programs\MinGW\bin;$(PATH) > to prepend the path to the 32-bit DLL just for the duration of the > build (kudos, btw!). Problem solved, the build is flawless. This should be the default PATH if you started the compiler from MinGW-Shell, i.e. MSYS, anyway. |
From: Earnie <ea...@us...> - 2011-12-14 12:35:53
|
Fabian Greffrath wrote: > Am 14.12.2011 04:20, schrieb manu0507: >> system most of the time. Fortunately, mingw32-make makes it possible >> to issue >> PATH := D:\Programs\MinGW\bin;$(PATH) >> to prepend the path to the 32-bit DLL just for the duration of the >> build (kudos, btw!). Problem solved, the build is flawless. > > This should be the default PATH if you started the compiler from > MinGW-Shell, i.e. MSYS, anyway. > Apparently the OP is not using MSYS. You can't use mingw32-make in MSYS anyway. The PATH setting in the Makefile is appropriate. Setting PATH via the Windows OS isn't advised. -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: LRN <lr...@gm...> - 2011-12-14 13:33:45
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14.12.2011 16:35, Earnie wrote: > Fabian Greffrath wrote: >> Am 14.12.2011 04:20, schrieb manu0507: >>> system most of the time. Fortunately, mingw32-make makes it >>> possible to issue PATH := D:\Programs\MinGW\bin;$(PATH) to >>> prepend the path to the 32-bit DLL just for the duration of >>> the build (kudos, btw!). Problem solved, the build is >>> flawless. >> >> This should be the default PATH if you started the compiler from >> MinGW-Shell, i.e. MSYS, anyway. >> > > Apparently the OP is not using MSYS. You can't use mingw32-make in > MSYS anyway. The PATH setting in the Makefile is appropriate. > Setting PATH via the Windows OS isn't advised. > Whenever i have to run MinGW outside of MSYS, i usually create a .cmd file that sets the proper environment (mostly PATH), and then runs its own arguments as a command in that enviornment (i.e. runs %*). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO6KWpAAoJEOs4Jb6SI2CwKkAH/jluNnE0/2DTHNwlViwPe61N pNW0E9okKeZjo78Ee5BI2rHE8oZq4+l4kvnz/tgJi7ZhI62tc9rZPPwHCgL3jSar gl5mOzBL5KepuWvrHeH2JtEIFMAG9BTSLYCwPcV2kASHPES6WR1EAUv5KvmTSmZb dVzYVZgTfJ6in+M+TegTEPZ28xCHWiaL30JndSbEikj1BzDscLwNg7H6xKcPznPK Pm2hcham13JiOX4ZDPQwxiR99mC/ERorXtIJKq9gAlX+KOQQ+A3BNPV2ZTltQiBl ap11aG7JDEG7cYHXMBiaBTy9SOZvWvKQkjpQnVkJZ10Tgc0JgAuIR9kdkD2nNRA= =JrOU -----END PGP SIGNATURE----- |