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.
Related
In particular, #include "sqlite3.h" gives an error [Clang Intellisense] Error: 'sqlite3.h' file not found in Visual Studio.
Everything works fine when compiling/running, but the intellisense errors are annoying.
I've installed sqlite3-dev and ran updates/upgrades.
I see sqlite3.h in the usr/include directory which is included in the list of intellisense directories under project properties.
sqlite3 is included in the Library names (Makefile settings -> Config settings)
Is my path going to the wrong library or am I just missing something simple? I don't see the sqlite.c file in there and looking the the .h file, I don't see the functions I am using (from an example) like SQLITE_OK or sqlite3_free.
Again, everything works, it's just the intellisense that doesn't work. At least from what I can tell so far.
Oh, and the code is running on raspbian if that matters.
Yes, I experience the same the first time I open the solution. But I managed to get rid of it by opening one of the included header files and a clean Rebuild.
my VS version is 2015
My question may completely be a noob. Sorry, for that but I have been trying to compile my first Cuda code in Xcode and I'm lost where and how I could set up the IDE to invoke NVCC.
I installed the latest CUDA toolkit CUDA 6.0 and have even installed GCC 4.8 using brew. I have XCODE 5.5
When I run my code from XCODE all the directives like global are marked as unidentified.
I don't where and to change the settings to invoke NVCC. I will be really thankful, if anyone could help me with this.
Further, when I created the XCODE project, I created it as a C project. So, I placed the CUDA code in this C file, which is what is giving me the above mentioned errors. I tried to replace this .C file with a .cu file (just change the extension), which too failed badly - XCODE didn't even know what to do with the .cu files
COuld anyone please help me?
Thanks in Advance
I have given it a try. Although I have not completely succeeded I thought I'd post my progress here in hopes of helping others. The steps I took were inspired by this page.
Create a new Xcode project
Under Build Settings add a new user defined setting CC with the value /usr/local/cuda/bin/nvcc.
Add /usr/local/cuda/include to Header Search Paths under Build Settings.
Set Enable Modules (C and Objective-C) to No.
Add /usr/local/cuda/lib/libcuda.dylib to Link Binary With Libraries under Build Phases.
For any C files you create set their extension to .cu in the File Inspector, after you have done that you have to set the type of that file to C source to get syntax highlighting, by going to Editor->Syntax Coloring->C.
Problems with this setup:
- Xcode can't run the executable, at least nog if it is compiled for debugging. However you can make it copy the executable to some reasonable location and run it in the terminal.
- Whenever you try 'Build for running' sometimes Xcode magically destroys the whole project.
I've installed the msp430-gcc compiler and associated tools to do some open-source msp430 development at home using Eclipse. I'm developing on a slightly older Macbook Pro running OS X Lion and installed the tools using MacPorts. I'm running Eclipse 3.7.2 with the CDT and GCC Cross Compiler Support plug-ins. I have a simple empty main() written that compiles and links just fine.
The ELF parser lets me view the contents of the ELF binary just fine with the exception of one component; when I try to view the contents of the startup code in crt0.S, it gives me a blank file. When I click on the crt0.S component of the ELF, the filename bar at the bottom of the Eclipse window shows "/opt/local/var/macports/build/_Volumes_work_mports_dports_cross_msp430-gcc/msp430-gcc/work/gcc-4.6.3/gcc/config/msp430/crt0.S". This makes sense because of my MacPorts install of msp430-gcc. crt0.S is archived into /opt/local/lib/gcc/msp430/4.6.3/libcrt0.a on my machine.
What I want to be able to do is tell Eclipse to look elsewhere for the source files for the libraries that are automatically linked when I build with the msp430-gcc toolchain. This would presumably include everything in /opt/local/lib/gcc/msp430/4.6.3/. I started by downloading the source for mspgcc-20120406 (the version in my MacPorts install) and applying the gcc patchfile to an empty directory tree. This created the gcc/config/msp430 directory, including the crt0.S and crt0ivtbl.S files.
What I have had no luck accomplishing is telling Eclipse to look in ~/Developer/mspgcc-20120406/gcc-4.6.3/config/msp430/ instead of the path that's in the already-built libcrt0.a. I tried playing around with the Project Preferences->Paths and Symbols->Source Location window, but didn't have much luck. I searched through this website and on Google and the closest thing I came up with was this question but it doesn't "smell" like the right answer.
I would like to avoid solutions that involve moving the library source into my project. I'd rather have a solution that will work for multiple projects.
All help is greatly appreciated! Thanks in advance.
Try and check if the Eclipse linked resource could help you declare that external directory from within your Eclipse project here.
Linked resources are files and folders that are stored in locations in the file system outside of the project's location. These special resources can be used to add files and folders to your project that for some reason must be stored in a certain place outside of your project. For example, a linked folder can be used to store build output separately from your source files.
I find interesting how you can define that linked resource:
Linked resource target paths can be either defined as absolute paths, or relative to a path variable.
Since you can define it relative to (for instance) your Eclipse project location PROJECT_LOC, you can then setup your resource in a way which won't change between two environments.
I'm having a strange problem with include files and an apparent disconnect between Eclipse's build process and its error reporting. I'll give detailed steps to reproducing this problem, so we can narrow the causes down as quickly as possible.
Eclipse 3.7.1 (Indigo SR1) for C/C++ Linux Developers, Ubuntu 10.10 64-bits
It all started when I imported an existing project that "makes" just fine on its own: I thought Eclipse would help considerably in navigating the files and figuring out what does what. However, some of the #included system headers seemed not to be having the correct effect in Eclipse's view. This was very puzzling, and in the course of investigating this, I managed to recreate the problem in a tiny sand box.
Step one: Create a new C project (File: New: C Project) using the Hello World ANSI C Project sample. The parameters are Executable: Hello World ANSI C Project/Linux GCC, the remaining Empty projects set to Linux GCC, and GNU Autotools set to Hello World ANSI C Autotools Project. Call it "hello". Be sure to generate the makefile automatically (Advanced Settings, I believe it is the default).
Step two: Adjust the include path. Using Project: Properties: C/C++ General: Paths and Symbols: Includes: GNU C, set the search path to /usr/local/include, /usr/lib/gcc/x86_64-linux-gnu/4.4.5/include, /usr/include. The second path depends on the exact version of gcc you have installed. This doesn't matter too much, as long as the build path includes at least /usr/include.
Now if you open hello.c, it looks very simple, and Eclipse is quite happy except for return EXIT_SUCCESS;, which cannot resolve EXIT_SUCCESS. Replace EXIT_SUCCESS with a zero (0) and Eclipse gives the all-clear. Select Project: Build Project to generate the executable.
Open a command-line window and drill down to your Eclipse workspace folder's hello/Debug subfolder. Once there, you can run the executable with the line ./hello.
Now the fun begins. Modify hello.c to read in its latter part:
#include <fcntl.h>
int main(void) {
printf("Hello World!\n");
int zz = SPLICE_F_MOVE;
printf("zz (SPLICE_F_MOVE) is '%d'\n", zz);
printf("Bye World!\n");
return 0;
}
You'll get an error on the int zz... line: "Symbol 'SPLICE_F_MOVE' could not be resolved". If you Build the project, you'll get a similar error in the console view: "error: 'SPLICE_F_MOVE' undeclared".
Now if you change the preamble to:
#define _GNU_SOURCE
#include <fcntl.h>
You still get the error on the int zz line (in the editor), but the project will Build correctly! You can confirm this by running the binary in the command-line window you opened earlier. This is really odd since examination of /usr/include/fcntl.h will show that it #includes <bits/fcntl.h>, and that latter header #defines SPLICE_F_MOVE (and a bunch of others) in a block guarded by #ifdef __USE_GNU (__USE_GNU gets #defined if _GNU_SOURCE is #defined). Why on Earth isn't our #define _GNU_SOURCE properly propagated in the workspace perspective?
So this is my problem in a nutshell: why is it the editor (and all of Eclipse CDT) reports an error (apparently by refusing to process correctly an include), but that the underlying build succeeds?
I had similar problems working with GNU and non-GNU compliant toolchains for cross-compiling various microcontrollers. CDT reports lots of errors, but the actual build works perfectly, even when all the header includes are correctly located in the project settings.
The problem is in how CDT operates as distinct from your make system build. CDT is a standalone lexer, parser, and preprocessor and doesn't make use of the toolchain you're using to do the build. This normally would work fine once you set the project settings to match those generated as command-line arguments to your build tools, but many toolchains frequently include hidden implicit defines as part of their compiler/preprocessor itself. The documentation for the implict/hidden defines is usually sketchy and incomplete in my experience, making it nearly impossible to determine which defines are set for a given toolchain (sometimes even dependent on build options) and what they mean. While it may look like you have all the correct defines set to reach the one you're having a problem with, I usually find (especially with GNU) that there are some you're missing that prevent the switch from being processed the way you expected.
When I debug something like this, I first make sure any headers in my project directory are found first if they have names matching those in other directories, then I slowly start moving headers from the standard include folder to my project folder. CDT doesn't do a very good job of indicating which possible versions of a header file it's parsing first, and it frequently pulls system environment settings when you least expect it, but it does look in your project folder for headers first (if you haven't set the system headers path in your project settings to take precedence). By moving the system headers from the location you're looking at to your project directory, you know for sure exactly which header file is being parsed by CDT. Furthermore, if you rebuild your index after doing the move, then open the file in Eclipse, CDT will indicate what switches it believes are enabled or disabled by greying-out or folding the branches not enabled in the header. Following this process has solved this exact problem for me every time, revealing when I had paths to multiple copies of the same header, accidentally duplicated headers, had defines or includes under unexpected switches, etc.
I have the same issue, but didn't even do anything that complicated to produce it--I just made a hello world project of the type you describe and get the same error. Note that, however, in my case, it may be due to a borked install of cygwin--for instance, I had other errors concerning failing to include the .h files, and a complete deletion/reinstall of cygwin removed those errors but the 'Symbol ... Could not be resolved' error remains.
I then decided to make a second such project, and they both report such an error in the 'problems' view, but only one of the projects actually shows the error underlined etc. in the editor (!)
Maybe this issue comes from Ijndigo itself. Did you tried the same with the latest Indigo SR2? I opened a number of bugs for Indigo and its SR1 in eclipse bugzilla.
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.