|
Notes |
|
|
(0022238)
|
|
Bill Hoffman
|
|
2010-09-15 17:42
|
|
|
I just tested this on my machine and although it is not specified as you claim, it did not cause any errors, and seemed to link just fine. Can you give a case where this fails? |
|
|
|
(0022242)
|
|
Scott
|
|
2010-09-15 18:16
|
|
This is the error I get, are you sure you are compiling 64 bit code?
3>LINK : warning LNK4068: /MACHINE not specified; defaulting to X86
3>NwUtils.dir\RelWithDebInfo\AppSettings.obj : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86' |
|
|
|
(0022243)
|
|
Bill Hoffman
|
|
2010-09-15 18:29
|
|
|
Yes, I just tested. I built Cmake with the Visual Studio 10 64 generator. The platform is x64 in the IDE. I have tried with both static and shared libraries and it works fine without that flag... |
|
|
|
(0022256)
|
|
Scott
|
|
2010-09-16 08:52
|
|
|
Hmm, I wish I knew how to fix it thru CMake. Right now, my only recourse is to manually change every project's "Target Machine" to /MACHINE:x64. Since this is a rather large solution with 25 projects, it's tedious to have to do it every time CMake regenerates. |
|
|
|
(0022259)
|
|
Bill Hoffman
|
|
2010-09-16 10:26
|
|
|
If you could create a small project that shows the problem, I would be happy to fix this for you. I don't want to make changes for something I can not reproduce. What if you create a static library target via the GUI does it set this flag? |
|
|
|
(0022391)
|
|
Scott
|
|
2010-09-30 10:27
|
|
Okay, I've attached the smallest project I found that reproduces the problem.
Steps to recreate:
Extract cmake-error-2010-win64.zip to a directory.
Run CMake to create a build directory at the same level as src.
Use Visual Studio 10 WIN64 generator
Hit configure twice, should get output like this:
Could NOT find CxxTest (missing: CXXTEST_INCLUDE_DIR)
CMAKE_MODULE_LINKER_FLAGS is /STACK:10000000 /machine:x64
CMAKE_EXE_LINKER_FLAGS is /STACK:10000000 /machine:x64
CMAKE_SHARED_LINKER_FLAGS is /STACK:10000000 /machine:x64
Could NOT find objcopy
Setting precompiled to $(ProjectDir)/$(IntDir)/stdafx.pch
Configuring done
Generate and open solution.
Switch to RelWithDebInfo
Build Solution.
You should get the following output showing the error with NwUtils project:
1>------ Build started: Project: ZERO_CHECK, Configuration: RelWithDebInfo x64 ------
1> Checking Build System
1> CMake does not need to re-run because C:/Dev/cmake-error-2010-win64/build/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because C:/Dev/cmake-error-2010-win64/build/NwUtils/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because C:/Dev/cmake-error-2010-win64/build/zlib/CMakeFiles/generate.stamp is up-to-date.
2>------ Build started: Project: zlib, Configuration: RelWithDebInfo x64 ------
2> Building Custom Rule C:/Dev/cmake-error-2010-win64/src/zlib/CMakeLists.txt
2> CMake does not need to re-run because C:\Dev\cmake-error-2010-win64\build\zlib\CMakeFiles\generate.stamp is up-to-date.
2> adler32.c
2> compress.c
2> crc32.c
2> deflate.c
2> gzio.c
2> infback.c
2> inffast.c
2> inflate.c
2> inftrees.c
2> trees.c
2> uncompr.c
2> zutil.c
2> Generating Code...
2> zlib.vcxproj -> C:\Dev\cmake-error-2010-win64\build\lib\RelWithDebInfo\zlib.lib
3>------ Build started: Project: NwUtils, Configuration: RelWithDebInfo x64 ------
3> Building Custom Rule C:/Dev/cmake-error-2010-win64/src/NwUtils/CMakeLists.txt
3> CMake does not need to re-run because C:\Dev\cmake-error-2010-win64\build\NwUtils\CMakeFiles\generate.stamp is up-to-date.
3> stdafx.cpp
3> Base64.cpp
3>LINK : warning LNK4068: /MACHINE not specified; defaulting to X86
3>NwUtils.dir\RelWithDebInfo\Base64.obj : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'
4>------ Skipped Build: Project: ALL_BUILD, Configuration: RelWithDebInfo x64 ------
4>Project not selected to build for this solution configuration
========== Build: 2 succeeded, 1 failed, 0 up-to-date, 1 skipped ========== |
|
|
|
(0022392)
|
|
Scott
|
|
2010-09-30 10:34
|
|
I would also like to add there's another bug wrt VS 2010. It does not reload the solution correctly. It works correctly with VS 2008.
With VS 2010, you get the following error:
---------------------------
Error
---------------------------
Operation aborted (Exception from HRESULT: 0x80004004 (E_ABORT))
---------------------------
OK
---------------------------
and the solution fails to reload without a lot of manual "Reload" messages on every project under the solution. I typically just close the solution and reopen, just to be sure it correctly gets the changes.
You can easily see this problem by editing my project src/CMakeLists.txt and changing line 103 to something like this:
add_definitions(-DBOOST_FILESYSTEM_VERSION=2 -DBOOST_FILESYSTEM_NO_DEPRECATED)
Then doing a Rebuild All from within VS 2010. |
|
|
|
(0022765)
|
|
Scott
|
|
2010-11-01 17:48
|
|
|
Any progress on this issue? |
|
|
|
(0022768)
|
|
Bill Hoffman
|
|
2010-11-01 21:35
|
|
I found the source of the problem:
http://connect.microsoft.com/VisualStudio/feedback/details/279482/linker-warning-lnk4068-if-first-file-is-a-resource-file-for-static-libraries [^]
So, in VS 2010, the resource file seems to want to come first when creating a library:
1>------ Build started: Project: NwUtils, Configuration: Debug x64 ------
1> Microsoft (R) Library Manager Version 10.00.30319.01
1> Copyright (C) Microsoft Corporation. All rights reserved.
1>
1> "/OUT:C:\Users\hoffman\Desktop\test\cmake-error-2010-win64\src\b\lib\Debug\NwUtils.lib" NwUtils.dir\Debug\NwUtils.res
1> NwUtils.dir\Debug\Base64.obj
1> NwUtils.dir\Debug\stdafx.obj
1>LINK : warning LNK4068: /MACHINE not specified; defaulting to X86
1>NwUtils.dir\Debug\Base64.obj : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'
========== Build: 0 succeeded, 1 failed, 2 up-to-date, 0 skipped ==========
In VS 9, it comes last (and works):
1>Copyright (C) Microsoft Corporation. All rights reserved.
1>"/OUT:C:\Users\hoffman\Desktop\test\cmake-error-2010-win64\src\bv9\lib\Debug\NwUtils.lib"
1>".\NwUtils.dir\Debug\Base64.obj"
1>".\NwUtils.dir\Debug\stdafx.obj"
1>".\NwUtils.dir\Debug\NwUtils.res"
So, the problem only shows up with static libraries that have resource files in them. And with the older VS versions the resource file came last. |
|
|
|
(0022771)
|
|
Scott
|
|
2010-11-02 08:34
|
|
Is this something that can be solved in CMakeLists.txt? It looks like I'm already putting resource files last:
add_library(NwUtils STATIC ${SOURCE_FILES} ${HEADER_FILES} ${RESOURCE_FILES}) |
|
|
|
(0022772)
|
|
Bill Hoffman
|
|
2010-11-02 09:44
|
|
No, it does not... I was not able to get VS 2010 to pick any different order.
There is a target property you could use.
So, this works:
set_target_properties(NwUtils PROPERTIES STATIC_LIBRARY_FLAGS "/machine:x64")
You will want to put that in some if checking maybe for
CMAKE_SIZEOF_VOID_P == 8 and MSVC...
This should of course be fixed in CMake, but that should get you going until the fix is done. |
|
|
|
(0022774)
|
|
Scott
|
|
2010-11-02 10:46
|
|
|
Okay, thanks for looking into this and the workaround. Is the VS 2010 solution reload issue getting fixed as well? |
|
|
|
(0025194)
|
|
Vladislav Vaintroub
|
|
2011-01-31 19:03
|
|
I see this as well. For me, this happens only with a single static library which is unique in that it has huge (I estimate 0000200:0000200-300) source files.
The whole project is about 100 targets, many of those static libraries. I can provide more info on how to reproduce it, if this is of any interest to anyone. |
|
|
|
(0025195)
|
|
Vladislav Vaintroub
|
|
2011-01-31 19:08
|
|
|
interesting markup here in mantis . I meant to say "200 to 300 source files" in the last comment |
|
|
|
(0026576)
|
|
staticinline
|
|
2011-05-24 13:26
|
|
|
I also got this error when building a 64-bit static library with an .rc file. The 'set_target_properties(NwUtils PROPERTIES STATIC_LIBRARY_FLAGS "/machine:x64")' workaround is working for me though. |
|
|
|
(0027540)
|
|
rvdn
|
|
2011-10-06 10:22
|
|
|
I also have this issue, but the workaround mentioned here doesn't work for us. Can we get a fix in CMAKE? |
|
|
|
(0027736)
|
|
Chris Scharver
|
|
2011-11-07 15:17
|
|
|
I'm also seeing this with a static library containing a resource file. Setting the STATIC_LIBRARY_FLAGS lets me work around this for the time being. |
|
|
|
(0029642)
|
|
edice
|
|
2012-06-08 00:14
|
|
|
|
|
(0029643)
|
|
edice
|
|
2012-06-08 00:29
|
|
An example of a library that has trouble with cmake 2.8.8 + msvc2010 + x64:
zlib 1.2.7 (can be downloaded from zlib.net) |
|
|
|
(0031798)
|
|
Andreas Mohr
|
2012-12-03 06:03
(edited on: 2013-04-25 12:46) |
|
Dito, hit the same issue with a SuperBuild when processing zlib.
This really needs to be pre-set correctly, soon - adding manual workarounds to a multitude of public projects is not the way to go.
I assume it's something that needs to be implicitly pre-configured by platform setup, i.e. [cmake_Modules]/Platform/Windows-cl.cmake
[edit] Nope, Bill Hoffmann above already said that it's likely to be a resource file build order problem.
I'll try to review it to see whether our resource file configuration actually is ok or whether something more obvious is problematic.
[edit] I don't think that this issue is as simple as "resource file not included as first file". In my case (zlib tested as standalone build) rearranging things (e.g. also by moving .rc into its own ResourceCompile-specific ItemGroup element) did NOT help.
[edit 2] Well, it easily might be - after all .vcxproj-side file list order arrangements can be completely unrelated to the actual order of input files as used by the tool's internal setup. And it's quite thinkable that that internal order possibly cannot be influenced on the .vcxproj side (i.e., CMake).
[edit 3] The lib.exe invocation is wrapped into a tracker.exe call, and if things got changed to a tracker.exe introduction post-9 (remember that msbuild is >= 2010 only!) then this is perhaps what changed the order of input files.
Detailed log level:
CMAKE_BUILD_EP_PREFIX = [CMAKE_BINARY_DIR]/SUPERBUILD__ZLIB-EP_PREFIX
ZLIB_EP_BINARY_DIR_INTDIR = [CMAKE_BUILD_EP_PREFIX]\SRC\SUPERBUILD__ZLIB-BUILD\ZLIBSTATIC.DIR\DEBUG
c:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\Tracker.exe /d C:\Windows\Microsoft.NET\Framework\v4.0.30319\FileTracker.dll /i [ZLIB_EP_BINARY_DIR_INTDIR] /r "[ZLIB_EP_BINARY_DIR_INTDIR]\ADLER32.OBJ|[ZLIB_EP_BINARY_DIR_INTDIR]\COMPRESS.OBJ|[ZLIB_EP_BINARY_DIR_INTDIR]\CRC32.OBJ|[ZLIB_EP_BINARY_DIR_INTDIR]\DEFLATE.OBJ|[ZLIB_EP_BINARY_DIR_INTDIR]\GZCLOSE.OBJ|[ZLIB_EP_BINARY_DIR_INTDIR]\GZLIB.OBJ|[ZLIB_EP_BINARY_DIR_INTDIR]\GZREAD.OBJ|[ZLIB_EP_BINARY_DIR_INTDIR]\GZWRITE.OBJ|[ZLIB_EP_BINARY_DIR_INTDIR]\INFBACK.OBJ|[ZLIB_EP_BINARY_DIR_INTDIR]\INFFAST.OBJ|[ZLIB_EP_BINARY_DIR_INTDIR]\INFLATE.OBJ|[ZLIB_EP_BINARY_DIR_INTDIR]\INFTREES.OBJ|[ZLIB_EP_BINARY_DIR_INTDIR]\TREES.OBJ|[ZLIB_EP_BINARY_DIR_INTDIR]\UNCOMPR.OBJ|[ZLIB_EP_BINARY_DIR_INTDIR]\ZLIB1.RES|[ZLIB_EP_BINARY_DIR_INTDIR]\ZUTIL.OBJ" /b MSBuildConsole_CancelEvent8f932d7161a54b43a8c40f12afea57aa /c "c:\Program Files\Microsoft Visual Studio 10.0\VC\bin\x86_amd64\Lib.exe" /OUT:"[ZLIB_EP_BINARY_DIR_INTDIR]\zlibstaticd.lib" /NOLOGO zlibstatic.dir\Debug\zlib1.res (TaskId:14)
1> (TaskId:14)
tracker.exe /r switch is "Root primary input file(s) being tracked".
OTOH it looks like there is one tracker.exe (for lib.exe) invocation per input file, and these invocations do start with the .res file (and this is the only lib.exe invocation in my log!), and since that fails (since this is the first file, which does not internally carry an architecture setting due to being a resource file, some architecture guesswork/defaults happen, and that FAILS) no further .obj files are being processed, so that contributes towards confirming the "VS build now changed to wrong file order" theory.
[end edit 3]
Some of my findings:
- a static library project usually does not have a link step in its build
- it does include a link step once a .rc file is contained in the list of source files
- since it usually does not have a link step, VS does not need to figure out the machine type from the .obj files generated
- but once we do have a link step (.rc file contained in project), building fails since the machine type required for linking .rc file parts is not specifically specified
- this can all be analyzed by reviewing VS project settings tabs of zlib solution (zlib vs. zlibstatic projects), and especially their "Command Line" tabs which do/don't contain /machine:... in the Linker tab
- so that means that for static libraries (or, perhaps more precisely, static libs containing .rc files) we likely need to have CMake specify /machine:... explicitly
- or does that mean that we should be specifying /machine:... for library targets in general?
|
|
|
|
(0031815)
|
|
Andreas Mohr
|
2012-12-03 07:56
(edited on: 2012-12-03 08:05) |
|
|
|
|
(0032944)
|
|
Andreas Mohr
|
2013-04-25 11:42
(edited on: 2013-04-25 12:00) |
|
== Random thoughts ==
http://stackoverflow.com/questions/1393704/compiling-c-static-library-for-64-bit-windows-platform-using-vs2008 [^]
seems to be exactly our issue, too.
A detailed VS build log for analysis can be gained via
MSVS2010 Tools -> Options -> Projects and Solutions -> Build and Run -> MSBuild project build output verbosity
However, that doesn't actually yield overwhelmingly helpful details (it just shows e.g. lib.exe - the Librarian - processing the .res file).
== Further analysis ==
We've got a problem where VS tools seem to have weak handling of resources within static libraries (see "VC++ resources in a static library" http://stackoverflow.com/a/15046578 [^] ). OTOH, *both* in a Win32 and an x64 build (via STATIC_LIBRARY_FLAGS /machine:x64 workaround, see above), the zlibstaticd.lib *does* receive the .res file content (InternalName etc. UTF-16 string data can be seen in binary).
So, it seems:
- VS has a long-standing librarian handling issue (LNK1112, see URL above) for storing .rc:s in static libs on non-Win32 $(Platform) setting (not too surprising given VS's general lack of polishing in many areas, e.g. zero-size .map files, grave .tlog cache inconsistency, project reload, astonishing non-performance)
- this results in a "problem" since zlib assigns .rc file to both shared (where this is nicely supported) *and* static (where this fails horribly) library. OTOH one could say that a *user* *should* be allowed to assign whichever input file types he wants to a target (with improper inputs being silently ignored). So perhaps CMake is missing an internal step which filters out .rc files for STATIC libraries? But this would be unsuitably hard-coded handling, I'd think...
- the issue of VS generators not generating specific TargetMachine elements for this x64 setting (which I mentioned in prior note) is irrelevant: an open-coded /machine:x64 is the usual handling as done by CMake's Platform modules. Also, the x64 setting *does* need to be specified much more generally (this configuration should simply be supplied open-coded from outside [Platform module content] since it's *not* specific to Visual Studio generator - nmake generator etc. most likely require availability of this setting as well since they're using the same build toolchain i.e. same issues)
- since VS does include .res data successfully once target machine is *manually, specifically* configured properly, this leaves us with the problem that the librarian (the <Lib> element within VS's tool configuration area) currently truly cannot be configured for x64:
while Platform/Windows-MSVC.cmake does set CMAKE_EXE_LINKER_FLAGS_INIT to /machine:${_MACHINE_ARCH_FLAG} and replicates it into CMAKE_SHARED_LINKER_FLAGS_INIT and CMAKE_MODULE_LINKER_FLAGS_INIT, which does get evaluated by cmVisualStudio10TargetGenerator.cxx ComputeLinkOptions(), *in addition to the CMAKE_<linkType>__LINKER_FLAGS variable* and the LINK_FLAGS *target property* and ultimately ends up in VS AdditionalOptions element of <Link> via linkOptions.OutputAdditionalOptions(), WriteLibOptions() first does its own dirty parsing (should be separated outside this method!), then considers the STATIC_LIBRARY_FLAGS **target property** only, which is a problem since then a /machine:x64 setting currently cannot be pre-configured from the outside (i.e., Platform modules), long before any targets come into play.
So, some current (master HEAD) CMake issues that I see:
- WriteLibOptions() (as opposed to WriteLinkOptions()) does dirty data gathering rather than *generation-only* handling of an *existing* dataset (--> cleanup required)
- we do want a default platform setup of AdditionalOptions /machine:${_MACHINE_ARCH_FLAG} for <Lib> (librarian) tool
- since we do want /machine:${_MACHINE_ARCH_FLAG} listed, we do need a specification and handling of a *librarian-specific* foo_INIT Platform variable. AFAICS, neither specification nor implementation nor use of this Platform variable currently exist.
since MSVS has both separate <Link> and <Lib> tool elements, this clearly is NOT a linker-related variable. So, which name would such a Platform variable carry? Are there any existing variables for such purpose?
Don't tell me it would be CMAKE_LIBRARIAN_FLAGS_INIT...
Nope, Modules/Generic-SDCC-C.cmake mentions:
find_program(SDCCLIB_EXECUTABLE sdcclib)
set(CMAKE_AR "${SDCCLIB_EXECUTABLE}" CACHE FILEPATH "The sdcc librarian" FORCE)
("The sdcc librarian", CMAKE_AR)
On a system here, CMakeCache.txt has:
CMAKE_AR:FILEPATH=/usr/bin/ar
So that would strongly hint at CMAKE_AR_FLAGS_INIT being the correct variable name. However,
$ grep CMAKE_AR *
gas.cmake: "<CMAKE_AR> cr <TARGET> <LINK_FLAGS> <OBJECTS> "
Generic-SDCC-C.cmake:# find sdcclib as CMAKE_AR
Generic-SDCC-C.cmake:set(CMAKE_AR "${SDCCLIB_EXECUTABLE}" CACHE FILEPATH "The sdcc librarian" FORCE)
Generic-SDCC-C.cmake: "<CMAKE_AR> -a <TARGET> <LINK_FLAGS> <OBJECTS> ")
Linux-como.cmake: "<CMAKE_AR> cr <TARGET> <LINK_FLAGS> <OBJECTS> "
OpenVMS.cmake: "<CMAKE_AR> cr <TARGET> <LINK_FLAGS> <OBJECTS>"
Windows-GNU.cmake: set(CMAKE_${lang}_ARCHIVE_CREATE "<CMAKE_AR> cr <TARGET> <LINK_FLAGS> <OBJECTS>")
Windows-GNU.cmake: set(CMAKE_${lang}_ARCHIVE_APPEND "<CMAKE_AR> r <TARGET> <LINK_FLAGS> <OBJECTS>")
Windows-GNU.cmake: "<CMAKE_AR> cr <OBJECT_DIR>/objects.a <OBJECTS>"
nowhere lists a CMAKE_AR_FLAGS*, and it shows CMAKE_${lang}_ARCHIVE_CREATE as making use of the <CMAKE_AR> generator expression (genex).
And a CMAKE_AR variable (or others) do *not* exist in my Windows-side x64 zlib CMakeCache.txt.
So, does VS <Lib> == lib.exe == CMAKE_AR --> CMAKE_CXX_ARCHIVE_CREATE?
There are some reasons to doubt that...
More verbosely, Windows-GNU.cmake contains:
if(MSYS OR MINGW)
# Create archiving rules to support large object file lists for static libraries.
set(CMAKE_${lang}_ARCHIVE_CREATE "<CMAKE_AR> cr <TARGET> <LINK_FLAGS> <OBJECTS>")
set(CMAKE_${lang}_ARCHIVE_APPEND "<CMAKE_AR> r <TARGET> <LINK_FLAGS> <OBJECTS>")
set(CMAKE_${lang}_ARCHIVE_FINISH "<CMAKE_RANLIB> <TARGET>")
Note that it's MSYS/MINGW-specific, but note that it does say "support large object file lists for static libraries".
However I'm currently having some doubts on whether the specific lib.exe command line as done by VS even is under CMake's control...
So maybe in the VS case we are NOT able to effectively specify a full MAKE_${lang}_ARCHIVE_CREATE librarian command line. IOW, we likely cannot and shouldn't specify that, but rather do Platform-have a and do generator-support a (currently not existing/used) CMAKE_AR_FLAGS_INIT Platform variable.
But I'm afraid I have to defer to the Platform setup wizards here on which way to best go... (the chosen solution ought to fit in cleanly with future plans on the LANGUAGE support / genex front).
Sorry for the rather long and possibly confusing note. But I'm happy to use the Edit button if requested (it's there for a reason :).
So, which way to go to finally get this annoying MSVC toolchain-originating issue solved? Thanks!
Side note: this was again a case where I managed to lose the entire form content during submission due to
invalid session token or whatever...
http://superuser.com/questions/236390/how-do-i-recover-a-form-in-firefox-without-installing-a-plugin [^]
had an awfully successful outcome. :)
And make damn sure to install Lazarus browser plugin *NOW* to avoid this in future...
(in many cases this manual recovery would NOT have worked!!)
== THE END ==
|
|
|
|
(0033520)
|
|
Sergei Nikulov
|
|
2013-07-09 10:20
|
|
I've discovered this issue is reproducible on curl project
cmake .. -G"Visual Studio 10 Win64" -DCURL_STATICLIB=ON
After I deleted .rc file from CMakeLists.txt or apply workaround using set_target_properties() for libcurl it builds just fine.
Here the mailing http://curl.haxx.se/mail/lib-2013-07/0046.html [^] |
|
|
|
(0034524)
|
|
xinyingho
|
2013-11-23 07:05
(edited on: 2013-11-23 07:06) |
|
I got the same error while compiling zlib after updating CMake.
I tested several versions and I can faithfully report that this bug is a regression that appeared between 2.8.9 and 2.8.10 RC1.
|
|
|
|
(0034532)
|
|
xinyingho
|
|
2013-11-23 18:26
|
|
I saw another comment above mine where it's stated that the bug can be triggered with 2.8.8. This is not my case. So here's more information on how I reproduced the bug.
I use Win7 64-bit, VS 2010 SP1 and zlib 1.2.8.
To compile zlib, I have a .bat with the content below:
del ".\CMakeCache.txt"
call "%ProgramFiles%\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /Release /x64 /win7
call "%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\VC\bin\x86_amd64\vcvarsx86_amd64.bat"
"%ProgramFiles(x86)%\CMake 2.8\bin\cmake" -G "NMake Makefiles" -DCMAKE_BUILD_TYPE:STRING="Release" -DCMAKE_C_FLAGS:STRING="/DWIN32 /D_WINDOWS /W3" -DCMAKE_C_FLAGS_RELEASE:STRING="/MT /O2 /Ob2 /D NDEBUG" -DCMAKE_EXE_LINKER_FLAGS:STRING="' /machine:x64 '" -DCMAKE_EXE_LINKER_FLAGS_RELEASE:STRING="/INCREMENTAL:NO" -DCMAKE_MODULE_LINKER_FLAGS:STRING="' /machine:x64 '" -DCMAKE_MODULE_LINKER_FLAGS_RELEASE:STRING="/INCREMENTAL:NO" -DCMAKE_SHARED_LINKER_FLAGS:STRING="' /machine:x64 '" -DCMAKE_SHARED_LINKER_FLAGS_RELEASE:STRING="/INCREMENTAL:NO" -DCMAKE_STATIC_LINKER_FLAGS:STRING="' /machine:x64 '" -DCMAKE_STATIC_LINKER_FLAGS_RELEASE:STRING="/INCREMENTAL:NO" .
nmake clean
nmake
With CMake 2.8.8 and 2.8.9, this script is done successfully. But starting with 2.8.10 RC1, the compilation fails at the linking stage saying this:
fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' |
|
|
|
(0038653)
|
|
Roman80
|
|
2015-04-29 20:02
|
|
|
This affects also CMake 3.2.1 |
|
|
|
(0038995)
|
|
Brad King
|
|
2015-06-29 10:23
|
|
|
|
|
(0040086)
|
|
Robert Maynard
|
|
2016-01-04 11:51
|
|
|
Closing resolved issues that have not been updated in more than 4 months. |
|
Property.png (54,003) 2010-09-15 17:34
cmake-error-2010-win64.zip (184,521) 2010-09-30 10:22