Apache OpenOffice (AOO) Bugzilla – Issue 13912
problem with unicows.lib
Last modified: 2004-08-23 15:54:37 UTC
Hi Hennes, I hope you can help (ref: http://www.openoffice.org/issues/show_bug.cgi?id=10727 ) Building 1.1 beta on Windows using tcsh, I get the following error: "unicows.lib(thunk_user32_wvsprintfW.obj) : fatal error LNK1103: debugging information corrupt; recompile module" The file unicows.lib is part of the Microsoft Platform SDK. The version I downloaded is of february 2003. Volker suggested to try editing .../sal/systools/win32/uwinapi/unicows.dxp and search for "wvsprintfW" and change it to ";wvsprintfW", but this did not work. Below is the output from dmake: Making: ../../../wntmsci7.pro/bin/uwinapi.dll guw.pl /cygdrive/c/progra~1/micros~2/vc98/bin/cl.exe -c -Fo../../../wntmsci7.pro /slo/uwinapi_version.obj -DWNT -I../../../wntmsci7.pro/inc /cygdrive/c/oo_1.1be ta_src/solenv/src/version.c Command: /cygdrive/c/progra~1/micros~2/vc98/bin/cl.exe Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86 Copyright (C) Microsoft Corp 1984-1998. All rights reserved. version.c guw.pl rc -DWIN32 -I -I. -I. -I../inc -I../../../inc -I../../../WIN/inc -I../.. /../wntmsci7.pro/inc -I. -I/cygdrive/c/oo_1.1beta_src/solver/644/wntmsci7.pro/in c/stl -I/cygdrive/c/oo_1.1beta_src/solver/644/wntmsci7.pro/inc/external -I/cygdr ive/c/oo_1.1beta_src/solver/644/wntmsci7.pro/inc -I/cygdrive/c/oo_1.1beta_src/so lenv/wntmsci7/inc -I/cygdrive/c/oo_1.1beta_src/solenv/inc -I/cygdrive/c/oo_1.1be ta_src/res -I/cygdrive/c/oo_1.1beta_src/solver/644/wntmsci7.pro/inc/stl -I/cygdr ive/C/progra~1/jdk131/include/win32 -I/cygdrive/C/progra~1/jdk131/include -I'/cy gdrive/C/Program Files/Microsoft SDK/include' -I/cygdrive/c/progra~1/micros~2/vc 98/include -I. -I../../../res -I. ../../../wntmsci7.pro/misc/uwinapi_def.rc Command: rc cat ../../../wntmsci7.pro/misc/uwinapi_def.res > ../../../wntmsci7.pro/misc/uwin api.res guw.pl link /MACHINE:IX86 @/tmp/mk610cb954.31 Command: link Microsoft (R) Incremental Linker Version 6.00.8447 Copyright (C) Microsoft Corp 1992-1998. All rights reserved. /MAP /NODEFAULTLIB /OPT:NOREF /RELEASE /DEBUG:notmapped,full /SUBSYSTEM:CONSOLE /DLL -out:../../../wntmsci7.pro/bin/uwinapi.dll -map:../../../wntmsci7.pro/misc/ uwinapi.map -def:../../../wntmsci7.pro/misc/uwinapi.def -implib:../../../wntmsci 7.pro/lib/uwinapi.lib ..\..\..\wntmsci7.pro\slo\uwinapi_version.obj ..\..\..\wnt msci7.pro\slo\uwinapi_description.obj ..\..\..\wntmsci7.pro\slo\CommandLineToArg vW.obj ..\..\..\wntmsci7.pro\slo\CopyFileExA.obj ..\..\..\wntmsci7.pro\slo\CopyF ileExW.obj ..\..\..\wntmsci7.pro\slo\DrawStateW.obj ..\..\..\wntmsci7.pro\slo\En umProcesses.obj ..\..\..\wntmsci7.pro\slo\GetLogicalDriveStringsW.obj ..\..\..\w ntmsci7.pro\slo\GetLongPathNameA.obj ..\..\..\wntmsci7.pro\slo\GetLongPathNameW. obj ..\..\..\wntmsci7.pro\slo\GetModuleFileNameExA.obj ..\..\..\wntmsci7.pro\slo \GetModuleFileNameExW.obj ..\..\..\wntmsci7.pro\slo\GetProcessId.obj ..\..\..\wn tmsci7.pro\slo\GetUserDomainA.obj ..\..\..\wntmsci7.pro\slo\GetUserDomainW.obj . .\..\..\wntmsci7.pro\slo\GetDiskFreeSpaceExA.obj ..\..\..\wntmsci7.pro\slo\GetDi skFreeSpaceExW.obj ..\..\..\wntmsci7.pro\slo\MoveFileExA.obj ..\..\..\wntmsci7.p ro\slo\MoveFileExW.obj ..\..\..\wntmsci7.pro\slo\toolhelp.obj ..\..\..\wntmsci7. pro\slo\DllGetVersion.obj ..\..\..\wntmsci7.pro\slo\DllMain.obj ..\..\..\wntmsci 7.pro\slo\ResolveThunk.obj ..\..\..\wntmsci7.pro\slo\snprintf.obj ..\..\..\wntms ci7.pro\slo\snwprintf.obj unicows.lib kernel32.lib user32.lib advapi32.lib versi on.lib msvcrt.lib ..\..\..\wntmsci7.pro\misc\uwinapi.res ../../../wntmsci7.pro/misc/uwinapi.def : warning LNK4017: DATA statement not sup ported for the target platform; ignored Creating library ../../../wntmsci7.pro/lib/uwinapi.lib and object ../../../wn tmsci7.pro/lib/uwinapi.exp unicows.lib(thunk_user32_wvsprintfW.obj) : fatal error LNK1103: debugging inform ation corrupt; recompile module dmake: Error code 79, while making '../../../wntmsci7.pro/bin/uwinapi.dll' echo: No match. ERROR: Error 65280 occurred while making /cygdrive/c/oo_1.1beta_src/sal/systools /win32/uwinapi dmake: Error code 1, while making 'build_all' echo: No match.
As seen in the out you're using the wntmsci7 platform. This will result in an incompatible mixup of compiler shipped import libraries and those from the PSDK. Use wntmsci9.
Hi Hennes, Following the instructions in http://tools.openoffice.org/servlets/ReadMsg?msgId=667367&listName=dev I changed in winenv.set the COMEX setting to 9 and all wntmsci7 to wntmsci9. I ran dmake clean, then source winenv.set, then dmake. The build stopped on the exact same error (the difference is that it now says "wntmsci9" instead of "wntmsci7" as in the below output from dmake). Please consider reopening the issue.
I reopened the issue! And set the priority to 1, target beta2 ! This is a serious problem for windows builds because you dont't get old PSDKs from Microsoft, only the current version, that doesn't work at the Moment. That means new PSDK installations cannot build OOo.
Now Prio 1
I can reproduce that. The latest Platform SDK from February 2003 requires Visual Studio .NET or Visual Studio 6 Service Pack 5. The OOo build requirements say Visual Studio Service Pack 3. Reason is that unicows.lib (any maybe some other import libraries) were created with the new .NET linker which creates a debug format that is not compatible with Visual Studio 6 linker. The PSDK Feb 2003 Release notes (http://www.microsoft.com/msdownload/platformsdk/sdkupdate/readme.htm ) state that the new PSDK is compatible with Visual Studio Service Pack 5. "Tested Compilers The Platform SDK has been tested with Visual Studio .NET and Visual Studio 6.0 Service Pack 5. Some samples may not build without applying the service pack. For more information about Visual Studio, see the Microsoft Visual Studio home page. The C/C++ SDK samples can be built with other compilers, but these are not completely tested by the SDK team. If you are using Visual C++ 5.0, it is recommended that you upgrade. The import libraries included with this release of the Platform SDK have a different format than that used by Visual C++ 5.0. The new format improves performance and decreases storage requirements. " I've not tested that because I can't patch the build environment here but installing the Service Pack should help. VS 6 SP 5 can be obtained her: http://msdn.microsoft.com/vstudio/downloads/updates/sp/vs6/sp5/defaul t.aspx Please apply the service pack patch and try again. If this works I'll submit an issue to update the OOo build requirements page.
I tested it and SP 5 didn't help. But here's a workaround: Removing /DEBUG from linker command line helps. Place the following at line 76 into /sal/systools/win32/uwinapi.mk LINKFLAGS!:=$(LINKFLAGS:S/DEBUG:notmapped,full /SUBSYSTEM:CONSOLE) As an alternate way you may specify a different link.exe. Use just that from the new Platform SDK !!! Inser the following at line 76: LINK="C:$/Program Files$/Microsoft SDK$/Bin$/Win64$/LINK.EXE" The "Win64" linker ist just MS .NET linker which is capable of all format. This causes no trouble because uwinapi.lib generated with the new linker is not a static library like unicows.lib.
>As an alternate way you may specify a different link.exe. Use just >that from the new Platform SDK !!! Inser the following at line 76: > >LINK="C:$/Program Files$/Microsoft SDK$/Bin$/Win64$/LINK.EXE" I would prefer this version if it works, I could add an commandline option to configure, e.g. --with-2003-psdk, that adds this LINK environment variable and sets COMEX=9 and the directorys to wntmsci9. COMEX=9 is still needed ?
I'm not sure if general usage of .NET linker from PSDK will cause trouble in other projects. I'd prefer a solution to only link uwinapi.dll with the new linker because unicows.lib is the only library that should cause trouble. Actually it's a static library with objects containing new (incompatible) debug information besides the exports look like as if it were an import library. So my suggestion is: Depending on the configure parameter --with-2003-psdk a define LINKVC7 should be set to ="C:$/Program Files$/Microsoft SDK$/Bin$/Win64$/LINK.EXE" (or an adequate path). In makefile,mk of sal/systools/win32/uwinapi the following should be placed at line 76: .IF "$(COMEX)=="9" .IF "$LINKVC7"!="" LINK=$(LINKVC7) .ENDIF .ENDIF BTW: I'm not quite sure about the meaning of COMEX. Does COMEX=9 mean using platform wntmsci9 ?
>I'd prefer a solution to only link uwinapi.dll with the new linker >because unicows.lib is the only library that should cause trouble. OK. >So my suggestion is: > >Depending on the configure parameter --with-2003-psdk a define >LINKVC7 should be set to ="C:$/Program Files$/Microsoft >SDK$/Bin$/Win64$/LINK.EXE" (or an adequate path). LINKVC7=$PSDK_HOME$/Bin$/Win64$/LINK.EXE somewhere >In makefile,mk of >sal/systools/win32/uwinapi the following should be placed at line 76: .IF "$(COMEX)=="9" .IF "$LINKVC7"!="" LINK=$(LINKVC7) .ENDIF .ENDIF >BTW: I'm not quite sure about the meaning of COMEX. Does COMEX=9 >mean using platform wntmsci9 ? What do I know, ause said: "9 ist hier MSVC 6 mit aktualisiertem PSDK." What is the current PSDK in hamburg environment? (ccing ause) It would be good if COMEX 7 means MSVC 6 SP3 to SP5, PSDK 10/2002 and COMEX 9 means MSVC 6 SP5, PSDK 02/2003. It would also be OK for me if we bump our build requirements to MSVC6 SP5 + PSDK 03/2003, but I had no time yet to check. With your proposed changes it should do. This would IMHO better than extra configure switches.
I tried to build sal with MSVC6 SP3 and 02/2003 PSDK, and it fails as expected, with the following patch the build of the module finishes. +++ sal/systools/win32/uwinapi/makefile.mk 6 May 2003 11:00:47 -0000 @@ -75,7 +75,7 @@ .IF "$(GUI)"=="WNT" - +LINK=$(WRAPCMD) $(PSDK_HOME)$/Bin$/Win64$/LINK.EXE SLOFILES=\ --- end of patch --- (Not usable yet, I know) What do you think, add the "--with-2003-psdk" switch to configure which just sets COMEX=9 instead of 7 for MSVC, and add something like: .IF "$(COMEX)=="9" .IF "$(PSDK_HOME)"!="" # Since the 02/2003 PSDK the "new" linker is needed here. LINK=$(WRAPCMD) $(PSDK_HOME)$/Bin$/Win64$/LINK.EXE .ENDIF .ENDIF to sal/systools/win32/uwinapi/makefile.mk I haven't tried a full build yet, but will start one in the evening.
Ok, just FYI, my build with MSVC 6 SP3, COMEX=7, wntmsci7, February 2003 PSDK and the hack with the +LINK=$(WRAPCMD) $(PSDK_HOME)$/Bin$/Win64$/LINK.EXE line completed. (cws...beta2)
Created attachment 6064 [details] Patch for configure.in
Created attachment 6065 [details] Patch for sal/.../makefile.mk
Committed the stuff. @vq: Please verify
Created attachment 6079 [details] PSDK_HOME may contain spaces, use this patch instead.
Heiner, I just realized that my patch fails for 02/2003 PSDK when PSDK_HOME contains spaces. (I didn't get this in my test, because my dir didn't contain spaces :-( ) Please add the quotes.
Sorry, s/Heiner/Hennes/ ;-)
Done
Is it OK that I also check in the generated configure?
@vq: It's O.K and you already did that ;-) @siombr: Please verfiy and close
Hi Hennes, Volker, I'm not sure if I understand all implications of this issue, but I was successfully able to build 1.1 beta 2 using VC6 SP5 and the new PSDK using the --with-2003-psdk option; I suppose that is sufficient verification :) You are the best!!!
mark as verified.
close issue.
close issue