incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mathias Bauer <mathias.ba...@numberfour.eu>
Subject Re: ucpp sal dependency (was Re: OpenOffice nightly)
Date Tue, 13 Dec 2011 09:25:07 GMT
On 12.12.2011 15:09, Ariel Constenla-Haile wrote:

> now on Windows:
>
> link
> /MACHINE:IX86
> /IGNORE:4102
> /IGNORE:4197
> @C:/cygwin/tmp/mkM2vC8q
> -safeseh
> -nxcompat
> -dynamicbase
> -NODEFAULTLIB
> -DEBUG
> /SUBSYSTEM:CONSOLE
> /BASE:0x1b000000
> -out:../../../../wntmsci12/bin/ucpp.exe
> -map:../../../../wntmsci12/misc/ucpp.map
>
> ../../../../wntmsci12/obj/assert.obj
> ../../../../wntmsci12/obj/cpp.obj
> ../../../../wntmsci12/obj/eval.obj
> ../../../../wntmsci12/obj/hash.obj
> ../../../../wntmsci12/obj/lexer.obj
> ../../../../wntmsci12/obj/macro.obj
> ../../../../wntmsci12/obj/mem.obj
> ../../../../wntmsci12/obj/nhash.obj
> msvcrtd.lib
> uwinapi.lib<---- SAL dependency
> kernel32.lib
> user32.lib
> oldnames.lib
> stlport_vc71_stldebug.lib
>
>
> LINK : fatal error LNK1104: no se puede abrir el archivo 'uwinapi.lib'
>
> dmake:  Error code 80, while making '../../../../wntmsci12/bin/ucpp.exe'
> dmake:  Error code 255, while making
> './wntmsci12/misc/build/so_built_ucpp'
>
>
> the solution for both errors on Linux and Windows seems to be
>
> UWINAPILIB=$(0)

Yes, that's the "unfortunate magic" I mentioned that the old build 
system applies. uwinapi.dll is part of the standard set of libraries 
that our dmake based build system uses automatically.

This automatic linkage against uwinapi.dll is a desperate attempt. The 
purpose of this library is to fix bugs in the Windows API by providing a 
wrapper with functions that have the same name as the buggy ones. 
Linking against that library before any Windows library is seen prevents 
the call of the buggy code.

uwinapi.dll was definitely needed on Win9x (here it might have served as 
a UniCode wrapper also, I'm not sure), but AFAIR also for some Windows 
API functions on Win2000 and WinXP. The problem with non-automatic 
linking against uwinapi.dll was that developers needed to know which Win 
API functions they use and if one of them is one of the buggy ones at 
least on one OS version. Obviously there wasn't enough trust that 
developers would be able to track that, so uwinapi.dll was linked to 
everything on Windows.

Perhaps it is worth the effort to check how much of uwinapi is still 
needed because the only possible platform that could benefit from it 
would be WinXP - and possibly some of the bugs have been fixed in 
service packs anyway. Getting rid of uwinapi would be nice.

BTW: another fix for the current problem would be converting ucpp to gbuild.

> LIBSALCPPRT=$(0)

Interesting, I didn't know that that such magic is active on Linux also 
(though I suspected that).

Good catch!

Regards,
Mathias

Mime
View raw message