We're using scons 2.3.4 and are in the process of upgrading to Visual Studio 2013 (from 2008).
In our scripts we do not set the /MANIFEST link flag. Instead we relied on the default behaviour to generate the manifest file.
This worked fine in VS2008. But on VS2013 the linker is not creating a manifest. This seems incorrect. According to the documentation /MANIFEST is still the default behavior in VS2013.
I've manual enabled the /MANIFEST flag in our scripts which sorts the problem out.
But I'm curious to know why this step is necessary at all?
"No manifest is required to locate the runtime DLLs since VS2010."
Found this to be true. There is no need enable the /MANIFEST flag at all.
Related
I'm trying to compile a C++ project in VS 2017. Previously I used VS 2019 but due to it's annoying bugs I moved back to 2017, but now I get and error: unknown flag "-pdbrpc" in "p2". I don't even know what this flag means and I didn't find it in .vcxproj files.
I tried to change my project's config settings to disable optimization, but didn't succeed. Also I searched that error in google but didn't find anything useful. How can I fix this annoying problem?
Had same problem. Disabling Whole Program Optimization fixed it.
You probably forgot to downgrade some projects you depend upon.
Make sure all of your projects (including static libraries you link with) use the same v141 (VS2017) Platform Toolset. It can be visible in the Solution Explorer as Project Name (Visual Studio 2017).
In my case I had a hidden project.default.props that was using $(DefaultPlatformToolset), which started to point to v142 as soon as I installed VS2019.
I have a Visual C++ solution with static and dynamic libraries, and one executable that uses these libraries. I'm currently upgrading from Visual Studio 2010 to Visual Studio 2015, I also upgraded the SDK version the projects use to 10.0.10586.0 (Windows 10).
Everything compiles and links correctly, except for one linker warning:
uuid.lib(unknwn_i.obj) : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
uuid.lib is part of the Windows SDK. It might have been compiled with /GL, but does that mean that every executable that gets linked against this library must use /GL? That would be pretty constraining. By the way, if I switch to Windows SDK version 8.1 (but still using Visual Studio 2015), the warning goes away.
I have a feeling that something else might be wrong here (even though the linker points to a very specific location), because I found zero Google references of this particular error with this particular object file, which is very strange...
Any ideas?
Edit:
The warning is present in both Debug and Release builds
According to link.exe with /VERBOSE, X.obj (and only that object) in my executable project is referencing unknwn_i.obj, that's why it is "pulled in". This project does not use /GL nor /LTCG at all (checked the project properties, each cpp file's properties in the project, and there are no "standalone" property sheets in the solution)
I also tried removing all libraries linked to the exe project from it's linkage list. When only the default ones were linked (kernel32.lib, uuid.lib, etc.), the warning still persisted (aside from tons of unresolved references, but that's because I intentionally removed libraries). So it's not external libraries that cause this issue.
I know this has been asked in other places and answered, but I'm having issues with MS Visual Studio 2010. I've developed a C++ executable but if I run the Release version on a machine that doesn't have the VC++ runtime library (ie, msvcr100d.dll), I get the "program cannot start because msvcr100d.dll is missing from your computer" error.
This is weird for two reasons:
Why is it trying to link with the debug version of the redistributable?
I tried applying this fix, setting the runtime library setting to /MT instead of /MD (multi-threaded DLL), but that only made the problem worse (if I manually copied msvcr100d.dll, it then said it couldn't find msvcp110.dll).
How can I package the runtime library with my executable so that I can run it on machines that don't have MS VC 2010 or the redistributable installed?
I know it's considered a security risk to include a copy of the DLL since it won't ever be updated, but my goal is just to send this executable to a few friends in the short term.
You definitely should not need the debug version of the CRT if you're compiling in "release" mode. You can tell they're the debug versions of the DLLs because they end with a d.
More to the point, the debug version is not redistributable, so it's not as simple as "packaging" it with your executable, or zipping up those DLLs.
Check to be sure that you're compiling all components of your application in "release" mode, and that you're linking the correct version of the CRT and any other libraries you use (e.g., MFC, ATL, etc.).
You will, of course, require msvcr100.dll (note the absence of the d suffix) and some others if they are not already installed. Direct your friends to download the Visual C++ 2010 Redistributable (or x64), or include this with your application automatically by building an installer.
For me the problem appeared in this situation:
I installed VS2012 and did not need VS2010 anymore.
I wanted to get my computer clean and also removed the VS2010 runtime executables, thinking that no other program would use it.
Then I wanted to test my DLL by attaching it to a program (let's call it program X).
I got the same error message.
I thought that I did something wrong when compiling the DLL.
However, the real problem was that I attached the DLL to program X, and program X was compiled in VS2010 with debug info. That is why the error was thrown.
I recompiled program X in VS2012, and the error was gone.
This problem explained in MSDN Library and as I understand installing Microsoft's Redistributable Package can help.
But sometimes the following solution can be used (as developer's side solution):
In your Visual Studio, open Project properties -> Configuration properties -> C/C++ -> Code generation
and change option Runtime Library to /MT instead of /MD
Usually the application that misses the .dll indicates what version you need – if one does not work, simply download the Microsoft visual C++ 2010 x86 or x64
from this link:
For 32 bit OS:Here
For 64 bit OS:Here
I got the same error.
I was refering a VS2010 DLL in a VS2012 project.
Just recompiled the DLL on VS2012 and now everything is fine.
Debug version of the vc++ library dlls are NOT meant to be redistributed!
Debug versions of an application are not redistributable, and debug
versions of the Visual C++ library DLLs are not redistributable. You
may deploy debug versions of applications and Visual C++ DLLs only to
your other computers, for the sole purpose of debugging and testing
the applications on a computer that does not have Visual Studio
installed. For more information, see Redistributing Visual C++ Files.
I will provide the link as well : http://msdn.microsoft.com/en-us/library/aa985618.aspx
I have used Visual Studio 2008 to compile and run CUDA applications before. I have switched to Visual Studio 2010 and Windows 7. I've been trying to get integration set up all morning, but haven't had complete success. I've downloaded the toolkit, installed Nsight, made sure the libraries/include/bin paths are set, checked the box to use a Build Customization of CUDA 3.2, and set the properties of the individual .cu file to be of type CUDA C/C++ instead of C/C++. I got an error about not supporting compiler v100, so I set the project platform to v90 and am downloading Visual Studio 2008 now. I was hoping that I wouldn't have to have two versions of visual studio installed, but oh well. Anyway, most of the syntax highlighting is enabled, some keywords like "int" is blue, comments are green, and strings are red. However, cuda-specific keywords like __ global__ aren't. Also, I've checked through the include directories and can't find cutil.h, so I'm wondering if there's anything else that wasn't included in the install of the 3.2 SDK (I have included cuda_runtime.h instead, but I don't know if this will solve my problems). Does anyone know how to fix this?
Edit: I have Visual Studio 2008 installed. When I try to compile, I get a giant list of errors, starting with 1>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\crtdefs.h(490): error : invalid redeclaration of type name "size_t", while most of the following errors have to deal with the size_t type. All of the errors are in included files, most of which I've never seen. Does anyone know what's going on? Or if there's a simple, step-by-step guide to getting VS2010 to use cuda?
Edit 2: Apparently I had one of the many current settings as 64-bit, and the others as 32-bit. Changing the active configuration, Cuda C/C++ Target Machine Platform, and Linker|Advanced Target Machine all to 32-bit or 64-bit allowed me to compile and run. I still don't have any idea how to fix the __ global__ and such syntax highlighting, but it's not that big of an issue.
You'll find a complete guide here:
How to Run CUDA In Visual Studio 2010
you can check if the source file that contains kernel is a CUDA/C file rather than a C/C++ file. (Solution Explorer -> File Properties)
In Visual Studio 2010, I'm trying to build an COM-interop enabled C# project without registering it during build, but I DO require the assembly's typelibrary (.tlb) file, so I can import it from another C++ project in the solution.
I haven't found a way of doing this - there once upon a time was a tlbexp.exe tool, but it was deprecated in favor of regasm.exe /tlb (which unlike tlbexp.exe, registers it).
tlbexp is still available in VS2010 here:
C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\TlbExp.exe