Ralf Habacker schrieb: > Alexander Neundorf schrieb: >> On Monday 04 August 2008, Ralf Habacker wrote: >> >>> Patrick Spendrin schrieb: >>> >>>> Ralf Habacker schrieb: >>>> >>>>> Hi, >>>>> >>>>> with recent svn source code (tested with cmake 2.6.0 and 2.6.1) I got >>>>> linker errors: >>>>> >>>>> >>>>> Scanning dependencies of target kde4-config >>>>> Linking CXX executable ..\bin\kde4-config.exe >>>>> LINK : fatal error LNK1104: cannot open file 'optimized.lib' >>>>> LINK Pass 1 failed. with 2 >>>>> >>>>> A look into the related build.cmake shows that the term >>>>> optimized;E:/daten/kde/emerge-msvc-root/lib/kdewin32.lib;debug;E:/daten/ >>>>> kde/emerge-msvc-root/lib/kdewin32d.lib from the CMakeCache.txt are >>>>> evaluated into >>>>> >>>>> optimized.lib >>>>> E:\daten\kde\emerge-msvc-root\lib\kdewin32.lib >>>>> debug.lib >>>>> E:\daten\kde\emerge-msvc-root\lib\kdewin32d.lib >>>>> >>>>> >>>>> The optimized.lib and debug.lib are complete wrong here and there should >>>>> only be one real library listed on the link line depending on the build >>>>> type. >>>>> >>>>> Short time ago this does work without any problems. Any hints how to >>>>> solve this problem would be very welcome because it is currently not >>>>> possible to release several important binary packages for the KDE 4.1 >>>>> release. >>>>> >>>> Exactly the same happens with the general keyword: it is not correctly >>>> used and thus produces strange errors (trying to link general.lib)- >>>> >>> The general keyword works for me with cmake 2.6.0 and 2.6.1 >>> >>> >>>> this seems to be a cmake related problem (maybe a buildsystem one as >>>> cmake worked with this before). >>>> >>> When I remove the optimized/debug libraries from the related _DEPENDS >>> lines in CMakeCache.txt and add a >>> general;E:/daten/kde/emerge-msvc-root/lib/kdewin32d.lib (for debug >>> builds) then there is no linking error. I assume that there is a problem >>> in the area where cmake parses the _DEPENDS lines. >>> >> We really need to get this fixed. >> It would be cool if you could find out what happens, I didn't have the >> problem >> yet on my system. >> Which buildtype have you set ? Maybe "DEBUG" ? >> >> The keywords "general", "optimized" and "debug" are handled in >> ------------ >> cmTargetLinkLibrariesCommand::InitialPass(). >> If there is a way that TARGET_LINK_LIBRARIES() ends up e.g. >> with "general;kdecore;debug;debug;kdeui;", i.e. two keywords behind each >> other, then this might cause the problem. The question is, can that happen ? >> It shouldn't. Can you find out whether that happens there ? >> > seems not to be. >> -------------- >> They are also handled in >> cmComputeLinkDepends::AddVarLinkEntries() and >> cmTarget::GatherDependencies(). >> These two functions may have the same issue, i.e. if the arguments they get >> contains two of the keywords in a row it might happen. >> Can check whether that happens ? >> > In this place there is some magic with compatibility I don't understand > yet. As there seems not to be a debug mode like qmake or autotools have > the only way to find what's going wrong is to add debug prints on > several places to see what happens inside - but this need cmake to be > compilable :-( I'll send you a patch. > > compiling with mingw would be an option for adding debug prints, but > further debugging is not an option because using command line gdb on > win32 is a night mare. > > Ralf ps > > _______________________________________________ > Kde-windows mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/kde-windows >
-- web: http://windows.kde.org mailing list: [email protected] irc: #kde-windows (irc.freenode.net) _______________________________________________ Kde-windows mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-windows
