incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J├╝rgen Schmidt <jogischm...@googlemail.com>
Subject Re: ucpp sal dependency (was Re: OpenOffice nightly)
Date Tue, 13 Dec 2011 16:01:10 GMT
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


Mime
View raw message