On 12/13/11 10:25 AM, Mathias Bauer wrote:
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.
i would love to do that, do you know if it's already possible to use
gbuild to apply our patch process and trigger a build on the patched
sources?
Juergen
LIBSALCPPRT=$(0)
Interesting, I didn't know that that such magic is active on Linux also
(though I suspected that).
Good catch!
Regards,
Mathias
