I am programming C on VSCODE but I have this annoying problem. When vscode automatically saves my work, it deletes the line that has the library inclusion that I need. So when I compile it gives me an error that I did not specify the function. Someone can help me?
I don't know how to resolve.
You might have installed a corrupted version of vs code or the library files of the vs code and then location where you are saving your programs might be in different location. For example
The libary files of vs code might be in c drive and the program files might be in onedrive folder.
Try reinstalling it from an authentic source if the second stated problem is not the case. If the problem still continues then please comment down on my reply.
Reinstall either from microsoft store or from
https://code.visualstudio.com/download
Related
i'm working with renesas MCU RX65N, i want to make a serial connection with other board and also display an HMI i designed on Appwizard, i followed the steps they offer on their manuals but won't work either. Then found more information about how to solve it, and the code works by itself, but when i try to merge both programs just keeps giving me errors (problems that doesn't appear on individual projects), this is the error i got now, and don't know what to do because apparently it is included for my project but won't open no matter what i try, anyone knows how to solve it or what to do?
It sounds like when you include the file in one project, it works, but when you include it in another project, it doesn't? It sounds like there is a configuration difference between your projects. Try creating a new file in a project, then just put #include "r_bsp_config.h" in it, or however you wrote it (it may need to be #include <r_bsp_config.h>). See if you get the same error (you will probably get an error, something about missing main(), but the question is whether you get the same error). If you don't, cut and paste the code from the problematic project in, and also make sure the project configuration is adjusted to match, and see if it works now. If you do get the same error, then see if you can copy the project configuration from the working project to the new project, and see if you get the error this time.
I got a makefile project for Linux and I want to compile it on Win10 with Visual Studio 2019.
There are some paths to files defined in the makefile as preprocessor defines.
I have to replace the paths by own created files because they are a kind of PLATFORM_HEADER and I have to adapt a new one to Windows. In the code it looks like:
#include PLATFORM_HEADER
The onliest I tried is to add a property sheet to my project and add a macro:
macro page of property sheet But this macro is not found in the project.
Changing the code is not possible because it is third party code and it must be able to become updated at later times without doing changes again.
In other instructions there is noted that a line called 'inherited property sheet' has to be modified in the project. But in VS2019 this line does not exist.
Thank you for your help!
This sort of problem will be handled by your compiler suite. Probably you'll deal this with your build process manager (make, bitbake, cmake...). You can ask it to pass these #defines as argument for the compilation (-D name=definition).
Now you've unlocked the "very most of fun" if you compile something meant for linux on windows since there are many way that can go wrong. You might want to do a full check of your environment variable when compiling and make sure they point to the right system librairies.
Probably it's worth giving a try to the windows subsystem for linux and other bindings / emulator. If you want to preview a week of work's outcome, maybe you can do it in a linux VM? or just get rid of windows one good time for all :)
While I was trying to compile a linux-kernel (v. 2.6.39) in Eclipse CDT, I have a not leaving problem about my include paths. I know this is a well discussed topic in the Internet, but all these solutions didn't fix my errors.
One of the errors is: **linux/kvm_host.h: No such file or directory**
one of the marked line in the source code is: #include < linux/kvm_host.h>
What I did (and actually expect to solve this problem):
In
Project Properties
C/C++ General
Paths and Symbols
I've added in "Includes", "Library Paths" the include directories:
e.g.:
- /[path-to-kernel]/linux-2.6.39/
- /[path-to-kernel]/linux-2.6.39/include
- /[path-to-kernel]/linux-2.6.39/include/linux
Still (after another make), it hasn't changed a thing.
So what's the matter, can someone give me a hint?
[Edit: As i mentioned in the comments, with STRG+Click on a underlined library it opens in my browser, so i believe it's just a problem of the Indexer but I think i have tryed everything in its options menu]
I just try to develop a fresh Linux kernel nothing special, I can't be the first one, doing this with a fresh eclipse.
After making a new project on the same kernel for the 3rd time it's working now. But still i don't have a clue why :/, since i rebuild the project an the indexer several times. I hope this won't be going on like this.
Thanks for your support!
I'm trying to migrate some C programs from Windows Server to Linux. To edit the code, I'm using Eclipse-Indigo. The machine on which I'm working has WinXP on it (not my choice, so no comments please). My eclipse workarea is on a samba shared drive which is in my home directory on the Linux server.
Each C program is in a separate makefile project. I have specified the cygwin gcc compiler/parser in the settings for new CDT Projects and selected all relevant error parsers in the makefile project settings.
There are no syntax errors showing and the errors that are listed seem somewhat bizarre. The first error states:
make: *** No rule to make target `../../../../../fiscus/vo/src/mk/e12_.mk'. Stop.
The make script at the end is wrong. There is a value in the name which comes from an environment variable. The path is correct exactly as shown but the script name has hte variable $(WA_PLATFORM) in it. This is not being resolved although I have specified the value in the build environment variables.
The subsequent errors are even weirder. For each subsequent project I get the message:
Program "make" is not found in PATH
This makes me wonder how the first message was generated. Besides, the path on my winXP environment, which I assume is the relevant one here, does indeed have the directory with the make program in it.
Where have I mucked it up? Any hints?
One last piece of information. When I shut down eclipse I get access violation errors for the following:
<workarea-path>\.metadata\plugins\org.eclipse.debug.ui\launchConfigurationHistory.xml
<workarea-path>\.metadata\plugins\org.eclipse.jdt.core\variablesAndContainers.dat
I find this to be suspicious...
The problem appears to lie in the fact that I was using the samba share as my workarea. Apparently the regular backups made on the server changed something (don't know exactly what, though). The projects were no longer being recognised as makefile projects and certain essential metadata files were not accessible. The permissions certainly were not the problem, since I checked those on the server (everything was set to rwxrwxrwx).
To solve the problem I copied the entire workarea to my local hard drive. I then pointed eclipse at this new workarea. The next step was a bit of a pain, because I had to delete each project (without deleting the source, of course) and then import "Existing code as Makefile Project". This can be done with "File->import..." or with a right-click in the package explorer and select "import...".
The last requirement is to specify the required "include" directories. This can be done with "Project-> Properties-> C/C++ General-> Paths and Symbols". Select the "Includes" tab, choose the language (in this case "GNU C") and add the directories where the headers are defined.
Now it works properly again.
I'm working off of a fresh install of VS 11 Beta, on a Windows 7 64-bit machine. When I try to debug, it gives me this error message.
"Unable to start program 'C:\Users\myname\documents\Visual Studio 11\Projects\Project1\Debug\Project1.exe"
I'm almost entirely sure it isn't a problem with my code--it works fine on online compilers, making me think that it's an issue with how I'm saving it. Just in case, here it is.
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
printf("Hello, world!\n");
return 0;
}
My process for creating the project/file is to create a new empty Visual C++ project, then a .cpp file, write my code, save it as a .c inside of the first folder I'm prompted with, within the projects folder, and then try to debug.
What am I doing wrong, here? I know that the debug folder is empty, but I can't figure out how to create the .exe file that should reside in it.
NB: I'm rather new to programming. If answers could be phrased in babyspeak, that would be appreciated.
Well, there could be a number of things wrong. However, based on your description of making a ccp file and a c file, I'm betting that it's a problem in your VS 11 project rather than the code itself. My guess would be that either the c file didn't get included in your project (check the Solution Explorer) or that you have the main (or _tmain) function defined in both the cpp and the c files, which will make the linker issue an error.
There are a bunch of "Hello World" tutorials online for VS 2010 and earlier, but there don't seem to be many for VS 11 Beta yet. You may want to take a look at the 2010 versions. I found this video tutorial that you may want to check out.
Check the output directory. And you can also set manually an output direcotry to save the built exe file.
I know this problem was from May but I thought I would answer with a solution that worked for me:
I was creating a .cpp file in a blank project and was getting a similar error. I noticed that the file had a name but was not showing the extension .cpp. I added the extension to the file (ex3.18.cpp) and did not get the .exe error again.
I don't know if that makes sense with your issue but I worked on this for two days uninstalling and reinstalling VS 11, and this was what finally worked.