First off, I did already check and found this question which is similar to my issue:
fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'
The solution there isn't usable though as VS2013 doesn't have the VC++ Directories settings anymore. It looks like those are configured through environment variables now, but I'm not sure how to fix this without borking the 32-bit builds.
====================================
I am working on porting a project from 32-bit to 64-bit code and so I created an x64 platform in my visual studio project. The debug build works fine, but the release build give me this error:
1>MSVCRT.lib(ti_inst.obj) : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
Setting the VERBOSE:Lib option, it appears to be trying to find the default system libraries in the x86 paths instead of x64. This pastebin includes the compiler and linker commandlines (yes, this is MACHINE:X64) as well as the VERBOSE:Lib output.
http://pastebin.com/Bqu0udRi
I'd like to know a) how do I fix this, and b) why would this only affect the release build? Looking at the library progress log for the debug build, I can see it is picking up the x64 paths and libraries correctly.
Perhaps it affect only Release build, because you have different properties set in this build configuration or different property sheets attached.
First of all, open Visual Studio, then go to Property Manager and expand Release | x64 configuration. Check if any other .props are placed above the Microsoft.Cpp.x64.user. If yes, check if they do not overwrite include/library directories.
Also compare what .props are attached in Debug | x64 configuration. Maybe some of them are required but not attached in Release?
If all this is fine, verify Microsoft.Cpp.x64.user itself. Go again to Property Manager, right click it and then Properties -> VC++ Directories. Check if Library Directories entry contains something like:
$(VCInstallDir)lib\amd64
$(VCInstallDir)atlmfc\lib\amd64
$(WindowsSDK_LibraryPath_x64)
The above entries are copied from my x64 .props file.
Lastly, switch to Solution Explorer and then check Project Properties - your project may have defined additional local directories, that are missing in this configuration (or shouldn't be present). Simply compare content in Debug and Release configurations.
Hope this helps.
One more thing:
You may also want to check global macros used by Visual Studio (or, to be more precise, what do they expand to). I ran into very serious problem once, after (with no reason) one of standard directory macro was overwritten to wrong value.
Related
We have a C++ CMAKE project. I work on it under Windows using Visual Studio 2019. My coworkers work under Ubuntu using QTCreator.
Here is what my current steps look like for swapping from a DEBUG build to a RELEASE build:
First set up VTK:
Open the release VTK build folder in Visual Studio and build the "INSTALL" subproject to overwrite the installed debug version of VTK with the release build.
Then set up our project:
Edit my account's PATH environment variable to point to the location of the new sub-project DLLs where Visual Studio will put them. (myProject\lib\analytics\Debug to myProject\lib\analytics\Release)
Without telling Windows where the sub-project's DLLs are, trying to execute the program does not work. Not sure if there's a way to tell Visual Studio to look for the DLLs automatically.
Edit the top-level CMAKE of the project:
SET(BUILD_MODE Release)
set(CMAKE_BUILD_TYPE "RELEASE" CACHE STRING "Sets release build by default")
Open Cmake-GUI and clear the cache, then run "Configure" and "Generate"
If I do not clear the cache, Cmake Gui has consistently used older/incorrect settings resulting in unusual build issues.
Open the project under Visual Studio, changing the build type at the top to my new choice.
Hit "Rebuild" on ALL_BUILD.
With all those steps done, I have managed to swap from a Debug to a Release build.
Is there some way to simplify this process and make it easier to swap between the two?
I am not very familiar with Visual Studio or Cmake, so I'm not sure what functionality I'm missing out on.
There should be no need to change reconfigure the cmake, project when using a multi configuration generator. This of course assumes that the VTK package provides imported targets via find_packag(VTK) that properly work with different configurations. You should be able to verify this by checking the import libraries for different configurations of one of your targets in Visual Studio: there are different import libs for the Release and Debug configurations, you're good to go.
As for enabling your program to find the dlls depending on the confiruation, when using the "Play Button" (Visual Studio Debugger):
You should be able to use generator expressions to modify PATH variable in the environment depending on the configuration.
The following assumes the dlls are located in .../lib/<vtk_component_name>/(Debug|Release) directories.
# should evaluate to "C:/Users/..../buildarea/.../lib"
# Note: it's very likely find_package(VTK) already provides necessary info
set(VTK_BASE_DIR "...")
set(VTK_PATH "")
foreach(VTK_COMPONENT IN ITEMS
data-manager
execution
...
)
# use vtk Release configuration for everything but the debug config
set(VTK_PATH "${VTK_BASE_DIR}/${VTK_COMPONENT }/$<IF:$<CONFIG:Debug>,Debug,Release>;${VTK_PATH}")
endforeach()
set_target_properties(my_exe PROPERTIES
VS_DEBUGGER_ENVIRONMENT "PATH=${VTK_PATH}$ENV{PATH}"
)
I am using a VS2015 to create DLLs which will be used in a project (which will be run on another PC).
I have build the DLLs in Release version on my PC but when I start the project on another PC, I get following errors:
VCRUNTIME140D.dll is missing
MSVCP140D.dll is missing
MSVCP140D.dll is missing
What steps should I take while creating these DLLs so that these debug runtime DLLs won't be required to the run the project on any PC.
In spite of it being built in release mode, if you require "...D.dll", then there are debug builds in the mix.
This could be the result of the third party dll you have or there are DEBUG or _DEBUG defines floating around.
Most likely is that the build (of the dll or the host exe) is explicitly set to use the debug version of the runtime (/MDd). Change this in the project settings to not use the debug version of the runtime (/MD).
Open the project's Property Pages dialog box.
Expand the C/C++ folder.
Select the Code Generation property page.
Modify the Runtime Library property.
To assist in the diagnosis of which binary is responsible for the debug dependency, you can use Dependency Walker to track down the offender. It will give you a list (as a tree) of the dependencies of each file.
In general, for missing the C++ runtimes (release version) on a target machine, you should install the C++ redistributable. As of this writing, VS 2015 redistributable is available here.
In C/C++ -> Code Generation -> set Runtime Library to:
Multi-threaded Debug (/MTd)
And yes, such setting is very much needed if you want to debug a process on a remote machine. So, don't go by others saying, "test with Release build only". Obviously, you'll need Remote Tools installed.
As stated by Niall, you should use dependency walker in order to find which part of the project is causing the error, it might not be the dll in issue after all.
My bet is it's just some part of the project you forgot and built in debug mode, which of should never be used for production as debug dlls are not included in C++ redistrib installers.
I am trying to build audEERING UG's openSmile library on Windows. I need to use this library with VS2005 but because setup with VS2005 isn't supported - my idea is to build it on VS2010 and then connect to VS2005 project. I can't somehow make it work so I will write step by step what I do:
I download latest openSMILE 2.1 version from official website: http://www.audeering.com/research/opensmile#installation
I open http://www.audeering.com/research-and-open-source/files/openSMILE-book-latest.pdf and read setup section for Windows
I open ide/vs10/openSmile.sln file with VS2010 and get this error:
error : Project "E:\Workplace\openSMILE-2.1.0\thirdparty\portaudio\build\msvc\portaudio.vcxproj" could not be found.
But I read in documentation that PortAudio is only one of variants so I ignore problem as I don't use it in my project:
You can select several configurations from this solution which represent the various combinations
of the standalone version (simply Release and Debug configurations) and support of OpenCV
and PortAudio (named accordingly).
I build openSmileLibClassif manually - done.
I build openSmileLibLibsvm manually - done.
I don't do anything iwth openSmileLibPortaudio
I build SMILEExtract manually and get an error:
error MSB4019: The imported project "E:\Workplace\openSMILE-2.1.0\openSMILE-2.1.0\ide\vs10\gnuGpl.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
I check in the project directory if there is gnuGpl.props file but I can't find it. I try to download previous version of the lib then: openSMILE-2.0-rc1. After unzip there is an gnuGpl.props file in the previous version. I copy it to 2.1 version.
Try to build SMILEExtract again. I get other error:
2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5): warning MSB8012: TargetPath(E:\Workplace\openSMILE-2.1.0\openSMILE-2.1.0\ide\vs10\Debug\SMILExtract_Debug.exe) does not match the Linker's OutputFile property value (E:\Workplace\openSMILE-2.1.0\msvcbuild\SMILExtract_Debug.exe). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).
2>LINK : fatal error LNK1104: cannot open file 'E:\Workplace\openSMILE-2.1.0\msvcbuild\openSmileLib_Debug.lib'
I think that maybe copying gnuGpl.props from previous project to new one is bad idea so I try to build openSMILE-2.0-rc1 instead and I get same error as in point 8.
Can someone tell me what am I doing wrong?
After I've deleted openSmileLibPortaudio from my project directory (because usage of it disables ASIO and I need it) and compiled project 3 times errors disappeared and I have only warning about considering output file location.
change your mode from debug to release!
in manual:
Important note for building on Windows: Some versions of Visual Studio
always select the "Debug" configuration by default instead of the "Release" configuration.
However, you always want to build the "Release" configuration, unless you are
an openSMILE developer. Thus, you mus always select the "Release" configuration
from the drop-down menu, before clicking on "Build Solution" !!
right mouse-key onopenSmileLib go to project->add->exist item,
choose src\examples\simpleMessageSender.cpp and click add to openSmileLib project, finally, recompile the code.
I'm attempting to compile a release executable using vs2012 Express. However, whenever I try to run the .exe on other computers, I get a warning that I need msvcr110.dll. I could simply copy the dll over, but I'm looking for a more long term solution.
In my attempts to isolate what is causing the error, I have reverted back to a new c++ project using the default settings, except for changing the configuration to release in the configuration manager.
I've been trying to solve this on my own for over a week now without any progress, so any suggestions would be appreciated.
Link to the CRT statically. Choose "Multithreaded", and not the DLL option in the Runtime Library dropdown in the project properties.
In your project properties choose option Configuration Properties/C/C++/Code Generation/Runtime Library and pick option 'Multi-threaded (/MT)' (or 'Multi-threaded Debug (/MTd)' for your debug configuration).
For dynamically linked applications, the Visual C++ Redistributable for Visual Studio 2012 must be installed in target machines. Be sure to choose the architecture that matches your application.
Statically linking will obviously work, too, but I tend to classify this as a workaround.
Whenever I create a new project in Visual Studio 2010 and don't set the specific platform (in my case x64) at first, I won't be able to completly change it afterwards.
So I setup everything a need with an external library (compiled as x64) and then press compile it obviously fails since the two platforms do not match.
sfml-graphics-s-d.lib(RenderStates.obj) : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'
Noticed that I change it to x64 with Build->Configuration-Manager->Active projectplattform->New...->x64. That's the same thing I'd do before doing anything else and it works, but if I do it afterwards I get the linker error:
libcpmtd.lib(uncaught.obj) : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'
The *.obj file can change from project to project (e.g. cout.obj) and from my understanding Visual Studio picks the x86 standard library and doesn't change it's decision after I've switched the platform.
So for the question: How do I force VS to use the new specified x64 platform - also for the standard library?
Note: Creating a new configuration setup will automatically change the linker setting for the target machine to: MachineX64 (/MACHINE:X64)
Note: Not sure if it's relevant but I'm linking the runtime library statically Multithreaded-Debug (/MTd)
If anyone would ever run into the same problems as I did, he can find the discussion and solution over at the MSDN 'forum'.
OK, I found it, LibraryPath corresponds to Library Directories property in VC++ Directories project property page. That explains what happened, that value is usually inherited so it changes automatically when you create add x64. But since you modified that value it is now local to the project and it simply gets copied when add x64... with all those x86 specific dirs.
I suppose it's simpler and safer to just add that lib dir in Linker\General\Additional Library Directories
Lukas' answer above is correct. However, there may be additional complications.
If changing your Library Directory path is not working, ensure your vcxproj file is not read-only or try editing the paths directly in the vcxproj file.
With the VS Perforce add-in, changing the Library Directories paths and building may not actually save your project file and you won't get a warning that the file was read-only, allowing the build to proceed with the old, incorrect settings.