I am trying to compile my fork of ReactOS using CMake 3.9.0-MSVC_2 (as included with Visual Studio 2017, 15.4 update). When I have CMake generate NMake makefiles or Ninja inputs, it works just fine. However, when I tell CMake to generate a Visual Studio 2017 solution, it fails with a weird error. Here's how to reproduce this issue:
Clone git#github.com:SunburstApps/ReactOS. (It's a big repo, so please be patient. I have not been able to consistently reproduce this issue on a smaller project, in case anyone asks.)
In the root of the project directory, run configure.cmd VSSolution from a VS2017 x86 C++ tools command prompt. This will tell CMake to generate a Visual Studio solution (the exact version is inferred from the copy of cl.exe in the path).
I get the following CMake output:
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:24 (project):
The CMAKE_C_COMPILER:
cl
is not a full path and was not found in the PATH.
CMake Error at CMakeLists.txt:24 (project):
The CMAKE_CXX_COMPILER:
cl
is not a full path and was not found in the PATH.
-- Configuring incomplete, errors occurred!
Investigating the CMakeError.log file reveals the problem is actually something else. The vcxproj file that CMake generated to identify the compiler is refusing to link, complaining that ucrtd.lib can't be found. If I add the following line of code to the top-level CMakeLists.txt file, it will then progress slightly further (successfully identifying the compiler), only to die of the same issue during a try_compile() run to "detect compiler features".
set(CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION 10.0.15063.0)
I have come to the conclusion that CMake is generating files without the Windows SDK target platform set, which is causing VS to refuse to locate ucrtd.lib. The set() line above tells CMake to add that specific version to the vcxproj files it generates, but clearly it doesn't add it to all of them.
I have tried other solutions I have found searching SO, including installing the Windows 8.1 SDK and running the CMake command as an administrator. Nothing helps. I need to generate a solution file so I can write code for this project using Visual Studio's excellent C++ editor. (I have also tried using the built-in CMake support in VS2017, but have found that it does not quite work due to ReactOS' specific cross-compiling requirements.) Can anyone give me some pointers? Thanks!
Related
I need the GhostScript 32-bit dll (gsdll32.dll) built to be compatible with Windows Runtime.
According GS's documentation, you can build the dll, from the source files, for WinRT apps.
See header 8.3.
Since I had no idea what I was getting myself into, I opened up the Ghostscript-winrt solution and tried to build it, and as you can imagine it outputted errors
The doc specifies how to build using Microsoft Visual Studio command line. But it's not very clear to the user who isn't experienced with nmake. For example,
The normal installation process for Microsoft Visual C++ includes setting the location of the Microsoft Visual C++ executables (cl.exe, link.exe, nmake.exe, rc.exe) in your PATH definition and the LIB and INCLUDE environment variables are set to point to the Microsoft Visual C++ directories. If this is true then the value for DEVSTUDIO can be changed to empty. I.e. DEVSTUDIO=
I don't know where these three environment variables are. I've the code thats called when I tried to build it:
nmake -f psi\msvc32.mak SBR=1 DEVSTUDIO= METRO=1 debug && nmake -f psi\msvc32.mak DEVSTUDIO= METRO=1 debugbsc
Any ideas based on the output what I need to set here?
I have been trying to rebuild the windows binaries for liblinear following the instructions in the Readme, using visual c++ and nmake. I need to rebuild because I need the SVM probability outputs. I modified the check_probability_model method in linear.cpp as suggested in the FAQ (https://www.csie.ntu.edu.tw/~cjlin/liblinear/FAQ.html#training_and_prediction). The build succeeds without errors but when I execute one of the binaries train.exe or predict.exe, they freeze/hang with no output. This happens also with the unmodified code. The included binaries in the zip file run fine.
Anyone got an idea what might cause this?
I have Visual Studio 2015 Community installed with visual c++ compiler. I used the 64 bit settings in the makefile.
I couldn't get igraph to work with Visual Studio 2010 (supposedly many known issues), and so decided to try installing it in Cygwin. ./configure went fine. But make gave this error:
f2c/dtime_.c:16:23: fatal error: sys/times.h: No such file or directory
Makefile:2190: recipe for target `libf2c_la-dtime_.lo' failed
make[3]: *** [libf2c_la-dtime_.lo] Error 1
I tried installing it in MinGW and get the same error when I make. Should I be providing "sys/time.h" or a path to it? Where is sys/time.h? Using Windows 7.
Edit
The problems in Cygwin and MinGW was due to the wrong version of gcc being used by my clean installation of Cygwin (and a characteristic of MinGW). Solution here: Installing/compiling in Cygwin/MinGW - How to set the include "path"? (symbolic link?)
The problem in Visual Studio 2010 was due to building in "Debug" instead of "Release". One of igraph's creator, Gábor Csárdi, graciously provided an excellent step-by-step guide below that identified and resolved it.
Igraph actually does work with Visual C++ 2010 Express, we test this before releases, and I have just tried it. You need to do the following steps.
Download the source package specifically created for Visual Studio.
Uncompress the file into My Documents\Visual Studio 2010\Projects.
Open the igraph.sln solution file in igraph-0.6-msvc\igraph-0.6-msvc directory from Visual Studio.
Visual Studio offers to convert the solution file to the current format, do that. Just click on Next, Next and Finish.
On the toolbar, change 'Debug' to 'Release' to make release builds.
Choose Debug -> Build solution and wait until the library is built.
To test it you can open the solution file in the igraphtest directory, convert it as well, choose 'Release' builds, and then build it and run it from the command line. It is a simple C++ program that uses igraph to create a graph and write it into the file out.txt.
You don't have to set up include and library directories at all, everything is set up properly in the solution file, both for igraph and igraphtest.
is there an sys/times.h file?
I have a vague memory that I had to make that symlink on a system once.
I am trying to build TSVN using Visual Studio and have followed all the steps of the build.txt but I am getting the following errors:
*****ERRORS********* Error 50 fatal error LNK1181: cannot open input file '../../ext/Subversion\release_win32\libsvn_repos.lib' TortoiseProc TortoiseProc
Error 1 fatal error LNK1181: cannot open input file '../../ext/Subversion\release_win32\libsvn_wc-nonet.lib' SubWCRevCOM SubWCRevCOM
The error messages suggest that you don't have all the required libraries. A few variants as to how yo got here:
you either misstyped the path to the include folder (where the .lib files are) - try searching for the files that are not found and adjust the include paths
OR
you have to build the project(s) in a certain order to avoid getting this error messages. Build the projects that output libsvn_repos.lib and libsvn_wc-nonet.lib first. Check the dependencies for each project and build first the projects that do not have dependencies on the other projects in the sollution
I haven't built TSVN myself so these are just guesses. But why don't you just use the install kit and avoid all this trouble ?
TortoiseSVN is a GUI front-end for Subversion, and it uses Subversion libraries as the back-end. Thus, you must compile Subversion or obtain the compiled binaries for your version of Visual Studio before compiling TortoiseSVN. After that, modify the paths that point to Subversion libraries to reflect your setup.
I am using VS 2003 .Net on 32 bit XP OS. I have also installed "Microsoft Platform SDK" on my machine. Can I build vc++ application (binaries) targeted for 64 bit OS?
I am using following project options :
Name="VCLinkerTool"
AdditionalOptions="/machine:AMD64 bufferoverflowU.lib"
OutputFile="\bin\Release\MM64.dll"
LinkIncremental="1"
SuppressStartupBanner="TRUE"
AdditionalLibraryDirectories=""C:\Program Files\Microsoft Platform SDK\Lib\AMD64""
GenerateDebugInformation="TRUE"
ProgramDatabaseFile="\bin\Release\MM64.pdb"
GenerateMapFile="TRUE"
MapFileName="\bin\Release\MM64.map"
MapExports="TRUE"
MapLines="TRUE"
OptimizeReferences="2"
EnableCOMDATFolding="2"
ImportLibrary=".\Release/MM64.lib"
TargetMachine="0"/>
I am getting following error:
fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'AMD64'
Do I need to build project on 64 bit OS or I need to change project settings to resolve this error.
Please help me to resolve this issue.
I had the same problem today, here's how I solved it (in Visual Studio 2008):
Went to Project Properties -> Linker -> Command Line -> Additional Options and removed the /MACHINE:I386 from the linker additional options.
Hope it helps
Having the same problem in VS2008. My solution was to change the active solution platform located in Build -> Configuration Manager and creating a new solution platform using the x64 and copuing the settings from Win32. This allowed me to use the pre-build 32bit libraries in my 64 bit OS.
For 64-bit Windows users:
I had the same problem today, here's how I solved it (in Visual Studio 2008): I went to:
Project Properties -> Linker -> Command Line -> Additional Options
and added the /MACHINE:I364 from the linker additional options.
This worked fine for me.
I faced above error when I tried to build my custom library for ARM64 in Visual Studio 2017. And my target machine was already ARM64 as expected.
Apparently, problem was in ARM64 compiler which was not installed(though I could run build in ARM64). I installed it by running Visual Studio Installer Individual Components -> Visual C++ compiler and libraries for ARM64
Next I got error MSB8022: Compiling Desktop applications for the ARM platform is not supported.
It was resolved by adding
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|ARM64'" Label="Configuration">
...
<PlatformToolset>v141</PlatformToolset>
<WindowsSDKDesktopARM64Support>true</WindowsSDKDesktopARM64Support>
</PropertyGroup>
into my project file.
After all of above I could succefully build my project in ARM64.
Hope it will be useful.
This error comes up because something in you build is being compiled in the wrong architecture (say as a x86 binary when everything else is x64). The linker panics and doesn't know what to do with it, so it breaks your build.
I can speak for your problem because the error message you quoted is incomplete. Usually it goes something like this:
SOME_KIND_OF_OBJECT.obj: fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'AMD64'
You look at the name of the obj file and you'll find the root of your problem there. Whatever obj is listed will have some kind source code analog with the same name. Have a look at it and see how it's being compiled. Usually all that stuff is automated in VS but sometimes there are special build steps that were added in by the developer. Inspect the custom, pre- and post- build events to see if a x86 tool is being used to assemble it. The property sheet in VS2010+ will be specific to the obj and the platform so you can inspect the library directories being used to verify that they are not 32 bit.