No, it is not the case. I checked it before already. As I have said test
compiles successfully with JDK 1.4.2b28, so path is OK. I even tried to
do as you have said right now (no jtreg, no MKS), and nothing changed as
expected. Test passes against jdk 1.4.2b28 and fails against jdk
1.4.2_39b02 and jdk 8b53.
LOG 1.4.2 u39 (dll is NOT produced):
C:\JTwork\scratch>nmake -f Makefile.win
Microsoft (R) Program Maintenance Utility Version 11.00.50727.1
Copyright (C) Microsoft Corporation. All rights reserved.
cl -nologo -IC:\jdk\j2sdk1.4.2_39b02\include\win32
-IC:\jdk\j2sdk1.4.2_39b02\include -c myfile.cpp
myfile.cpp
link -nologo -dll -out:mylib.dll myfile.obj gdi32.lib
user32.lib -LIBPATH:C:\jdk\j2sdk1.4.2_39b02\lib jawt.lib
Creating library mylib.lib and object mylib.exp
myfile.obj : error LNK2019: unresolved external symbol
__imp__JAWT_GetAWT@8 referenced in function _Java_MyCanvas_paint@12
mylib.dll : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio 11.0\VC\BIN\link.EXE"' : return code '0x460'
Stop.
LOG 1.4.2 fcs (no errors, dll is produced):
C:\JTwork\scratch>nmake -f Makefile.win
Microsoft (R) Program Maintenance Utility Version 11.00.50727.1
Copyright (C) Microsoft Corporation. All rights reserved.
cl -nologo -IC:\jdk\j2sdk1.4.2b28\include\win32
-IC:\jdk\j2sdk1.4.2b28\include -c myfile.cpp
myfile.cpp
link -nologo -dll -out:mylib.dll myfile.obj gdi32.lib
user32.lib -LIBPATH:C:\jdk\j2sdk1.4.2b28\lib jawt.lib
Creating library mylib.lib and object mylib.exp
LOG 8 b51 (dll is NOT produced):
C:\JTwork\scratch>nmake -f Makefile.win
Microsoft (R) Program Maintenance Utility Version 11.00.50727.1
Copyright (C) Microsoft Corporation. All rights reserved.
cl -nologo -IC:\jdk\jdk1.8.0b51\include\win32
-IC:\jdk\jdk1.8.0b51\include -c myfile.cpp
myfile.cpp
link -nologo -dll -out:mylib.dll myfile.obj gdi32.lib
user32.lib -LIBPATH:C:\jdk\jdk1.8.0b51\lib jawt.lib
Creating library mylib.lib and object mylib.exp
myfile.obj : error LNK2019: unresolved external symbol
__imp__JAWT_GetAWT@8 referenced in function _Java_MyCanvas_paint@12
mylib.dll : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio 11.0\VC\BIN\link.EXE"' : return code '0x460'
Stop.
On 28.08.2012 17:46, Anthony Petrov wrote:
On 8/28/2012 5:13 PM, Konstantin Shefov wrote:
Why is this necessary? This must be a bug in JDK if the library
still needs to be copied to the current directory on Windows. Could
you verify if the test still works w/o copying the dll? It must,
actually.
I cannot verify it on JDK 8 (Windows only issue, Solaris and Linux
work fine) because on Windows this test compiles only with JDK 1.4.2
fcs b28! Even if I use JDK 1.4.2 u39 b02, I have the following
compiler error:
link -nologo -dll -out:mylib.dll myfile.obj gdi32.lib user32.lib
C:/jdk/j2sdk1.4.2_39b02\\lib\\jawt.lib
I believe this line causes the error. The linker simply doesn't see
the jawt.lib module. Please try using the following name for the module:
"C:\jdk\j2sdk1.4.2_39b02\lib\jawt.lib"
instead of the current one:
"C:/jdk/j2sdk1.4.2_39b02\\lib\\jawt.lib"
(note the changes in slashes). I think make and/or cygwin/MKS can
mangle the file name. There must be a way to make them return a proper
full path name for the file so that the linker could see the module.
Actually, I suggest to pass the following option to the linker:
-LC:\jdk\j2sdk1.4.2_39b02\lib
and list the jawt.lib simply by name together with other .lib's you're
linking against.
Please try this and see if it works for you.
--
best regards,
Anthony
Creating library mylib.lib and object mylib.exp
myfile.obj : error LNK2019: unresolved external symbol
__imp__JAWT_GetAWT@8 referenced in function _Java_MyCanvas_paint@12
mylib.dll : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: '"C:\\Program Files (x86)\\Microsoft
Visual Studio 11.0\\VC\\BIN\\link.EXE"' : return code '0x460'
It seems there is no "__imp__JAWT_GetAWT@8" in jawt.lib since 1.4.2
fcs...
--
best regards,
Anthony
On 8/27/2012 8:29 PM, Konstantin Shefov wrote:
Hello,
Please review a fix for the issue:
7190587 Open source and jtreg'ify JAWT regression test
Test was modified in to be run with jtreg.
The webrev is http://cr.openjdk.java.net/~kshefov/7190587/webrev.00/
Thanks,
Konstantin
