I know a question like this was already asked, but the situation is a little different, and all the answers on that problem didn't work for me.
I'm trying to compile some C code in VS2008 and it doesn't create an exe. Also, when I try to run it with f5, I get:
This application has failed to start
because MSVCR90.DLL was not found.
I did some googling and it said that this was because my c++ redistributable package wasnt installed. So I installed that, restarted everything and tried again. But alas, I still get the same error. Does anyone have any clue how to fix this?
It sounds like either a problem with your VS2008 installation, or something wrong with your DLL search path. MSVCR90.DLL is installed when you install VS2008, you shouldn't have to install any additional redistributable packages.
First I would check your PATH environment variable and make sure there is no gobbledydook in it that will break some of the entries, and if you don't find a problem there, then I would uninstall and reinstall Visual Studio.
You could also try searching for MSVCR90.DLL (and other DLLs like it), and move them to your Windows/System32 folder.
If you just want to get going now, another thing you could do is change your project to statically link to the runtime libraries, and then it wont even try to load that DLL. Go to your Project settings, Configuration Properties->C/C++->Code Generation and change Runtime Library from Multi-Threaded DLL to just Multi-Threaded (or any of the options that doesn't end with DLL).
Here are some things to check for your configuration of the project- under the general tab:
.1 Configuration type - exe in your case.
.2 Use of MFC: if this is an MFC application it might be more portable if you do: Use MFC in a static library.
.3 Use of ATL - if not using atl (or not sure) say Not using ATL.
.4 Under C/C++ -> Runtime Library: Say Multi-threaded Debug (for debug version) or Multi-Threaded (for release version).
If you are getting specific linker errors that say something is already defined:
This means that you have some parts of your app (separate libs being linked to your exe) that are built with different runtime linking:
You can:
Make sure that these libraries were compiled with the same version of visual studio as your application.
Change those projects to use static runtime: C/C++ -> Code Generation -> Runtime LIbrary: /MT or MTd (same as #4 above)
If you still have some specific errors try telling the linker to ignore certain libraries: Go to Linker->Ignore Specific Library and put in the library that you want to ignore. This is most common for 'libcmt.lib' or 'libcmtd.lib'. It is important also to know that lib ending with 'd' is usually the debug version. If you are creating a release build and you are getting 'already defined in libcmtd.lib' that means that somewhere you are linking a release lib to a debug lib.
if you delete the manifest file associated with you .exe, you will get the same error.
MSVCR90.dll is not installed in system32, but in the side-by-side folder, hence the manifest is required.
I have just been bitten by this and this page got me working again.
The key is to ignore MSVCRT and MSVCR90 libraries for the debug configuration. Set your linker -> Input -> Ignore Specific Library setting to include the following:
MSVCRT
MSVCR90
it is supposedly in the http://www.microsoft.com/downloads/en/details.aspx?FamilyID=a5c84275-3b97-4ab7-a40d-3802b2af5fc2&displaylang=en visual studio 2008 runtime library. Yes! After installing that, openoffice update works.
If you give the finished exe to someone else they will need to install the latest visual c runtime to run it. This will only work for release build AFAIK. Visual studio should install the required runtime both release and debug into your path. The project probably has an additional dependency accidently set for an incorrect version of the runtime.
See if this page helps.
Go to your Project settings, Configuration Properties->C/C++->Code Generation and change Runtime Library from Multi-Threaded DLL to Multi-Threaded and then try to compile but it won't. Then change it to Multi-Threaded Debug and try to compile ,but it won't again and then you change it back to Multi-Threaded DLL and then it should compile and run.
Related
Compiler: MinGW-W64 GCC-8.1.0 (x86_64-posix-seh)
Missing library: graphics.h
It seems like this library was not installed by default. If such case is true, where can I get it?
As a side note, I am not interested in installing a full IDE like Visual Studio just to use this one library.
After looking into this for 5 minutes, I think you will need to install either sdl-bgi or WinBGIm. Since MSYS2 doesn't seem to have packages for these, you would need to compile those projects from source. This means you would need to figure out the correct set of configuration optiosn and possibly fix any build errors. If you do succeed in doing that, you might consider contributing your work as an MSYS2 package so others can benefit from it ( https://github.com/Alexpux/MINGW-packages ).
I've been programming C for a while with Visual Studio, but now switched to CLion. My programming and target system is Windows10.
Within Visual Studio, I was able to include the required DLLs like "vcruntime140d.dll" and "ucrtbased.dll" inside my exe.
I did this by going into the project settings and set configuration settings - C/C++ - code generation - runtime library to "Multithreaded-Debug (/MTd)".
Doing this I was able to run the resulting exe without having errors like "vcruntime140d.dll is missing" or "ucrtbased.dll is missing".
But how can I achieve this within CLion?
I've been searching for a while now, and I found a lot of tutorials on how to include .lib files but not for DLLs (I don't have the code for).
With Clion, you actually are working with CMake. So the question is to be like how to link dlls within CMake.
There are many ways to do. e.g.
link_libraries
target_link_libraries
If the library could not be found by default, use find_library to search for it.
If these functions seems too strange to you, check this tutorial from the CLion team.
Update
As in the comment you asked, your problem is how to load a dll without lib. To address this, you could dynamicly load the dll, or make a lib from the dll.
For Windows multicopies problem, add following into your CMakeLists.txt
foreach (flag_var
CMAKE_C_LINK_FLAGS
CMAKE_C_LINK_FLAGS_DEBUG
CMAKE_C_LINK_FLAGS_RELEASE
CMAKE_CXX_LINK_FLAGS
CMAKE_CXX_LINK_FLAGS_DEBUG
CMAKE_CXX_LINK_FLAGS_RELEASE
CMAKE_EXE_LINKER_FLAGS
CMAKE_EXE_LINKER_FLAGS_DEBUG
CMAKE_EXE_LINKER_FLAGS_RELEASE
CMAKE_C_FLAGS
CMAKE_C_FLAGS_DEBUG
CMAKE_C_FLAGS_RELEASE
CMAKE_C_FLAGS_MINSIZEREL
CMAKE_C_FLAGS_RELWITHDEBINFO
CMAKE_CXX_FLAGS
CMAKE_CXX_FLAGS_DEBUG
CMAKE_CXX_FLAGS_RELEASE
CMAKE_CXX_FLAGS_MINSIZEREL
CMAKE_CXX_FLAGS_RELWITHDEBINFO)
string(REPLACE "/MD" "-MT" ${flag_var} "${${flag_var}}")
endforeach ()
I have made a dll in Microsoft Visual Studio 2005. Then i am trying to use it in other project on the other computer in CodeBlocks IDE. Project is built, but when it use functions from dll i got an error: "The program can't start because MSVCR80D.dll is missing from your computer. Try reinstall the program to fix this problem". How to build my dll without dependences on MSVCR80D.dll or build in this MSVCR80D.dll?
You're trying to run a debug version, which is linked to the debug version of the CRT. The latter is only available where VS has been installed. You should use the release version of your project on other machines (or manually copy all the dependent debug DLLs, which is not legal according to the license...).
UPDATE 1:
My original post was too long and obscured the real problem. I have discovered exactly what is causing the "Multiple targets" bug when Make is called.
UPDATE 2:
I found out that this 'Multiple Targets' bug is caused by GNU Make version 3.8.1 (see here1 and here2). GNU Make 3.8.1 is the current GNU Make released with Cygwin. To summarize the link: The old v3.8.0 handled windows paths fine and the newer v3.8.1 reports errors for windows paths (maybe it's a passive aggressive jab from the FSF?).
When you start a new project in Eclipse+CDT+Cygwin w/o external includes/libraries, everything works fine for me.
As soon as I try to use an external include/library I get the "Multiple targets" bug.
Here is exactly the steps needed to reproduce the bug on Windows+Eclipse+CDT+Cygwin:
Project project properties --> C/C++ Build --> Settings --> Tool Settings --> Cygwin C Compiler --> Includes --> Include Paths (-I) -- > Add Button --> Pick directory --> "C:\dir1\dir2"
I hit build.
It builds with no errors the first time.
I hit build again... I get build errors "Multiple targets. Stop.".
I click on the error.
Eclipse pulls up a makefile. The error happens when make sees the windows path for the new include file from the external library:
# NOTE: Error happens when the first "C:/" occurs
src/main.d src/main.o: ../src/main.c C:/dir1/dir2/ExternalLibrary.h
The reason for Make getting an error "Multiple targets" is because it sees the ":" which is part of the Make syntax for declaring a target. When there are two ":", Make errors out because it doesn't know what to do with "Multiple targets."
I can not edit the makefiles manually because they are immediately regenerated and overwritten [UPDATE: by Eclipse-CDT]. Given that I can't manually edit the makefile.
Is there any way for Eclipse to NOT use the "C:\" path? or tell make to ignore the "C:\" path?
Is this an Eclipse+CDT+Cygwin bug?
If you use Eclipse+CDT+Cygwin... please lend a hand (I don't want to use Visual Studios...)! Maybe I am using Eclipse+CDT+cygwin wrong? How do YOU get External Library includes to work?
*Very very frustrated*
Trying to stay Open-Source and cross-platform user,
Trevor
Turns out the "multiple targets" issue is caused by the current version of GNU Make installed from Cygwin. GNU Make 3.8.1 is the current GNU Make released with Cygwin.
The GNU Make 3.8.1 does not handle windows paths that contain "C:\". So every time your make file has a windows path with "C:\" you get a build error "multiple targets".
The solution I ended up doing is to download a fixed GNU Make v3.8.1. See Here1 or Here2. Then Eclipse+CDT+Cygwin worked fine again.
Update (05-feb-2015):
With an updated cygwin and a new Make (4.0.x) then the problem goes away.
https://superuser.com/questions/154418/where-do-i-get-make-for-cygwin
Had a such a problem, too. Problem was that I included paths on the project settings. Then I had absolute paths. When including the paths in the folder settings with relative paths it worked fine.
I still Got the same problem with eclipse/CDT Juno after update cygwin
to fix it:
you need make 3.80-1 or older and this needs cygintl-2.dll.
download make3.80-1 from
http://www.filewatcher.com/m/make-3.80-1.tar.bz2.286814-0.html
and the needed Dll from
http://www.dllguru.com/cygintl-2.dll.html
extract it somewhere
rename your make in cygwin/bin to makeVersion e.g. make3.82.90
copy cygintl-2.dll and make into cygwin/bin
try build your project in eclipse twice, the problem should be disappeared
gerdi
I'm just starting out writing trying to write a simple program in C and I am using Visual Studios to do so. I heard that it does compile C as well as C++. And I know that it does because it says it compiles. The only problem is that when I go to the output directory, there isn't a .exe file in the directory! It has the following:
BuildLog.html
mt.dep
test1.obj
vc90.idb
vc90.pdb
But that is all! No EXE. I've looked through all the options and made sure that it is set to compile to an exe and i checked the output file. That is $(OutDir)\$(ProjectName).exe. But alas, no exe appears. Any ideas?
Also when i try to hit f5 and run with debut i get an error that says
This application has failed to start
because MSVCR90.DLL was not found.
Re-installing the application may fix
this problem
By default when you're creating a new C++ project within a new solution, you're getting folder structure like this:
C:\Projects\YourSolution
C:\Projects\YourSolution\YourCppProject
YourSolution contains YourSolution.sln and YourCppProject contains YourCppProject.vcproj.
When you build the solution, all intermediate files from YourCppProject are getting stored under YourCppProject\Debug or YourCppProject\Release, but resulting YourCppProject.exe goes under YourSolution\Debug or YourSolution\Release.
Your $(OutDir) is configured by General -> Output Directory. Check project configuration for YourCppProject and see that it uses $(SolutionDir) for the output.
is it a C/C++ console application?
did you use the project wizard to create it?
do you have a function like
#include "stdafx.h"
int _tmain(int argc, _TCHAR* argv[])
{
printf("Hello, world!\n");
return 0;
}
in a .c module, typically main.c?
what happens when you hit F5 to run-with-debug?
what does your build log look like?
The simplest thing to do is just start over, making sure you choose the right kind of project.
To compile plain old C code with Visual Studio, choose Visual C++ > General > Empty Project from the New Project menu. This creates 3 empty folders: Header Files, Resource Files, and Source Files. Right click on Source Files, choose Add > New Item. Then add a main.cpp, rename it to main.c, and start coding.
http://msdn.microsoft.com/en-us/library/ms235299.aspx
Note:
It is not supported to redistribute
C/C++ applications that are built
without a manifest. Visual C++
libraries cannot be used by C/C++
applications without a manifest
binding the application to these
libraries. For more information, see
Choosing a Deployment Method.
If the DLL is not reachable and
Windows cannot load this DLL for your
application, you may get the following
error message:
This application has failed to start
because MSVCR90.dll was not found.
Re-installing the application may fix
this problem.
To resolve these errors, you must make
sure that your application is built
correctly and Visual C++ libraries are
correctly deployed on the target
system. To identify the root cause of
these run-time errors, follow the
steps outlined in Troubleshooting
C/C++ Isolated Applications and
Side-by-side Assemblies.
HTH
Sounds like you only hit compile, that will give you you're .obj file, but you still need to click build.