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