Trouble compiling with msvc80 and possible solution
Michael Leupold
lemma at confuego.org
Sun Aug 23 17:06:51 CEST 2009
Michael Leupold schrieb:
> Ralf Habacker schrieb:
>> Michael Leupold schrieb:
>>> Hi there,
>>>
>>> I tried emerging KDE today and had some trouble compiling. I hope
>>> this has not been brought up before:
>>>
>>> On msvc80 (2005) kdewin's own manifest tool mt.exe clashes with the
>>> one supplied by the compiler. With the standard environment cmake
>>> always detected the one in %KDEROOT%\bin first but assumed it was the
>>> Microsoft one.
>>>
>>> Thus it tried to compile like this:
>>> -----------------
>>> D:/kderoot/bin/mt.exe /nologo /out:automoc4.exe.embed.manifest
>>> /notify_update /manifest automoc4.exe.intermediate.manifest
>>> -----------------
>>>
>>> Obviously this won't work because the mt.exe called doesn't
>>> understand command-line options given with / as a prefix (I tried
>>> changing to "-" and it worked). Instead you end up with an empty
>>> manifest and binaries which don't find their runtime library.
>>>
>> this issue is fixed in svn - please run
>> emerge --update kdewin
>
> Thanks, mt.exe works fine now.
>
> However I seem to face another bug. It seems cmake uses a wrong build
> order and executes mt as the LAST tool (even after linking). That almost
> looks like a cmake bug, is it? Logs attached.
Alright, I found something :-)
cmake uses the /notify_update switch on mt.exe (which seems to be
undocumented at least on my version). If this switch is set, mt.exe will
set its return value to 0 if the output file wasn't modified and to
1090650113 (magic :-)) if the output file was rewritten. Apparently
that's meant to save some time relinking.
Recompiling mt.exe with that magic value set as rc (unconditionally)
makes it work.
I also found this related commit to cmake which contains an explanation:
http://www.cmake.org/pipermail/cmake-commits/2008-January/002891.html
Regards,
Michael
More information about the Kde-windows
mailing list