I am having a strange problem with Code:Blocks. After writing C program i click on Build and run, it compiles in fraction of a second but then a new window opens and after around 12 seconds output appears on the window.
It takes this much time for even basic code like
#include<stdio.h>
int main()
{
printf("HELLO");
return 0;
}
Here are snapshots of what happens. As I am not allowed to post images{new to forum} I am posting links.
When I click on build and run, this window appears in no time
Then after around 10-12 seconds, this window appears. As you can see it says that execution time took 11 seconds.
Any idea why this is happening? How to fix it? I did no tweaks to code:blocks and settings are same as they come by default.
The problem was with antivirus. Whitlisting gcc,g++ and codeblocks solved the problem.
I faced the same issue. Later I found out that, its due to antivirus. I don't have any antivirus install in my PC. It was windows Virus and threats protection which was running all the time, which make execution slow.
What I did is, Go to Manage settings. After that you will found Exclusions somewhere. Go to exclusions. Then go to Add/remove exclusions.
There just add the folder where your .c or .cpp file is created. And then you are done.
Adding a youtube link which can be useful
[https://www.youtube.com/watch?v=OaQQsDIsc8o]
For any Avast user reading this
Open the interface
Go to settings
Go to general
Scroll down and you will find 'exclusion'
Enter the directory in which your CodeBlocks is installed. Also enter the directory in which you have saved your project.
What is the setting of Settings -> Compiler -> your compiler -> Build options -> Number of processors?
For your CPU it should be 8-12. This option will help you if you have many files. If you have 1 file it doesn't matter.
p.s. you've not mentioned what compiler you're using, so this might be the cause.
p.p.s. gcc on windows is slower than the linux version, 2x and more times slower...
Even without antivirus, Windows Defender(in Windows 11) was slowing it down for me.
When I excluded the folder, it started to work faster for me.
Steps for excluding the folder from Windows Defender scan in Windows 11 (10 might be same I guess):
Open up Windows Security app.
go to Virus and threat protection.
Under Virus and threat protection settings, click Manage settings.
Scroll to last, under Exclusion click on Add or remove exclusions.
Click yes for the permission.
there you can add the file/folder to exclude from.
Now build and run your code, it should run faster. If not then sorry your problem seems to bigger than this solution.
Related
I'm a beginner in C++ and I started an Udemy course. In that course they recommend using CodeLite as IDE, so I decided to give it a try. In the course, they write a basic program that displays "Hello world!" to show how the IDE works. They compile then execute it, and a terminal window opens with the "Hello world!" message like normal.
In my case, after following the setup process step by step and using the exact same code as them, when I compile and execute the code, my terminal flashes for a split second and then disappears. In their video the terminal remains open but I thought that since they have an older version of CodeLite maybe in the newer one that I have, the terminal is supposed to close by default.
I went online and found people saying that a way of keeping the terminal open is by adding #include and system("pause"); on Windows, but in my case the terminal keeps behaving the same, and CodeLite doesn't report any problems. I've also tried cin.get(); with no success.
Any idea what could be causing this problem?
I had the same problem and I did these steps to solve the problem:
Uninstalled CodeLite.
Installed MinGW correctly.
Then reinstalled CodeLite.
Then did tutorial steps: Click Scan then select MinGW.
After I did these steps, it worked normally.
I had the same problem running Codelite on OpenSuse Leap 15.1. I eventually found a very simple answer. Go to the Settings menu, select Preferences and then Terminal, on the left towards the bottom. Change it to konsole to use the standard terminal, rather than the codelite-terminal.
I know this is an old question, but did not see the answer that worked for me. Debugging (F5) will close the terminal after completion.
However, running/executing (CTRL+F5) will not. Leaves terminal open. At least this is the case for me, and hopefully this helps someone out.
I know this is an old question, but CodeLite has a Project-level setting for "pause when execution ends" which will pause the program before the terminal closes so that you can see outputs and the like.
To turn on just right click on your project, go to settings, and it should be in the center of the general tab.
I went online and found people saying that a way of keeping the terminal open is by adding #include and system("pause");
And this is the wrong way to do it - the desire to leave the window open/closed is not meant to be controlled by your program; but the thing calling it. For example, you break the ability to run it as part of a headless script.
Much better would be to run it in debug and put a break point at the return of main, or to find the configuration option in your IDE that stops it closing the window.
I am not aware why CodeLite would behave like that. If you really added some pause or blocking call and it still closes, it looks like it is not really running the program (e.g. something breaks before that or something is misconfigured).
First, try to open a terminal yourself (e.g. cmd or PowerShell on Windows), and execute your compiled program there -- that way, the terminal will remain open. If that works, then compilation went fine, but something is wrong with CodeLite's configuration, most likely.
Otherwise, as a last resort, since using CodeLite is not strictly required, simply switch to another IDE/toolchain, e.g. Visual Studio (on Windows).
For some reason, after closing and reopening CodeLite, it now works, the terminal remains open when I run it from the IDE. I don't know what solved the problem since I've closed and reopened CodeLite at least 5 times before this without anything happening. Thanks for the help though.
I had the same issue. What I found wrong was that the compiler that I installed was 32bit and I was using the 64bit CodeLite version . Try Installing the 32bit CodeLite version and it should work fine.
It worked for me.
I had this problem also, I tried uninstalling and reinstalling code lite but the problem still occurred.
I went back and checked the Environment Variables in control panel and I had placed the systems variables in "Path" to the incorrect Bin directory.
I corrected the entry, uninstalled and reinstalled code lite again and the problem was resolved.
Hey I also had the same problem, doing the same course! What I did was to relocate my mingw-w64 folder, deleted the earlier path from environment variables and added the new path. I uninstalled CodeLite; not saving the user information. I actually downloaded the 14.0.0(64-bit) instead of the newer version 14.0.1(64 bit) . Then I did the steps that Frank tells you and it worked out for me.
I am completing the same Udemy course and encountered a similar problem of the console closing immediately. I encountered the problem for a workspace with 1.) a long name and 2.) ending with an underscore "_". I reduced the size of the folder name which also involved deleting the trailing underscore. This appears to have solved the problem. I encountered this problem with one of Frank's provided workspaces so I knew it was not a compiler issue.
I had an issue with section 20 of my Udemy course because it had parenthesis in the workspace folder name. "(STL)" at the end. Once I got rid of the special characters, it worked fine.
If pause("system"); or cin or restarting Program and whole PC solutions are not working, then make sure to:
Copy your code.
Create new Project and past your code there.
Make sure the new project is selected before trying to double-click it.
Notes:
You can now delete the old not working project and rename your new project.
I don't know what's the reason of the problem, but I did that and it worked for me.
You need to make sure if it is 64bits CodeLite then you have installed 64bits MinGW. Through the IDE itself, you can re-run the setup wizard
Restarting Codelite worked for me ...
I installed Visual Studio Code 1.1 with the C/C++ extension,
opened my C++ project and tried to use "Go to definition" in vain.
The "Go to definition" is not working at all.
Example, go to definition of a class member:
int i = m_myVar;
(I opened a simpler project with one file and it was working for this one)
In the end, what I want is good indexation of my big project, is there a way to install Intellisense?
I had a the same issue: F12 and Ctrl + Click and Right Click "Go To Definition" wasn't working.
The fix for me was:
Go to Extensions
Click "Disable All Installed Extensions"
Close and Reopen VS Code
Back to Extensions and "Enable All Extensions"
Essentially enable/disable all extensions fixed the issue.
I recently came across this same issue and after trying all of the suggested solutions I could find with no success, I found this article:
https://code.visualstudio.com/docs/setup/linux#_visual-studio-code-is-unable-to-watch-for-file-changes-in-this-large-workspace-error-enospc
Basically my project grew too large and VS code was no longer able to track all files, which messed up the "go to definition" functionality.
After following the steps on the link to increase the maximum number of files to be tracked, the issue was resolved.
The correction is pretty simple (tested on Ubuntu 18.04):
Add this line:
fs.inotify.max_user_watches=524288
to the end of the file /etc/sysctl.conf
After saving, run the following command:
sudo sysctl -p
Hopefully this will be useful to someone else, this has been bothering me for the last few days.
I had a similar problem except with Python and google searches for solutions kept bringing me back to this post so I figured I'd post my solution here in the hopes that it might help other people.
I was working on a remote cluster through VScode Remote and was getting similar errors to the original question(all 'go to ___' functionality was unavailable and was even getting a 'too large to track' error) and I thought I had to increase the number of watches, which didn't end up helping.
All I needed to do was install a python interpreter on the remote VScode server. This fixed my problem.
I believe vscode 1.1 (well, 1.1.1 actually) + the C++ extension (cpptools) is as much Intellisense as we can get for now.
You should load your big project with the "open folder" function to make vscode know about the other files.
https://blogs.msdn.microsoft.com/vcblog/2016/03/31/cc-extension-for-visual-studio-code/ warns about letting the indexing finish first (red icon in lower right corner during indexing) and mentions the current limitations on the source code parsing.
It wasn't working on my laptop as well after installing a few VSCode extensions. I decided to close and re-open VSCode with administrator permission and suddenly it sorted out.
I have been trying to fix this for a long time. In the end, what worked for me was simply reinstalling VSCode, then installing the latest C/C++ extension (v0.18.1). Then, in your .vscode/c_cpp_properties.json file, under includePath, add your include folder which has all your header files.
I tried the methods mentioned in this thread none of them seemed to work for me. A simple solution that worked for me is that I closed the current workspace and created a new workspace, added the folders which I required(same as the old workspace), and saved the new workspace. Waited for a couple of minutes to index and IntelliSense is able to find definitions now.
I am using VSCode 1.52.1 on Ubuntu 20.04.
In my case, for whatever reason,c_cpp_properties.json has become set to Disabled in ~/.config/Code/User/settings.json.
Manually changing it to Enabled solved the problem.
Fixed mine by UNCHECKING C_Cpp > Default > Limit Symbols To Included Headers
Your mileage may vary. Good luck!
Have you saved your workspace? Or did you just open a folder with File->Open Folder? This question already has many answers, but none of them address this case, which was my issue.
The question is not specific enough for me to know if you are having the exact same symptoms as my case.
If:
You have not saved your workspace. vscode doesn't say "(workspace)" at the top of the window.
None of the goto functions are working, but instead report: "No ___ found for ____"
The tag parser database icon in the bottom right is always there but only reports "Parsing open files", rather than telling you how many files have been parsed.
Then:
Try saving your workspace.
If you have multiple versions of a language on your PC, specify the exact language you are using in the VScode(in my case, I am using Python, so I must specify the version to the python Interpreter in VS Code)
If you could not do it whatsoever, then uninstall all the other versions that you don't use and then if you go to VS Code, it will ask the version to be used, and you would have only one version, so when you select the version, the "Go To Definition" will be activated.
I was having a similar issue with java on Ubuntu 20.04 using OpenJDK version 11 (openjdk-11-jdk in apt). At first I didn't have the JRE installed, so I installed it and it still didn't work.
Afterwards, I went to the CTRL + SHIFT + P menu and then to Java: Configure Java Runtime, there I saw in the Java Tooling Runtime tab that /usr/lib/jvm/java-11-openjdk-amd64 was selected, changed it to /usr/lib/jvm/java-1.11.0-openjdk-amd64 just to see if it would work, and after a restart it did. I'm not sure why this is, but I hope it may help somone else.
For python ensure your code analysis settings are correct. In my case the languageServer was accidentally set to 'None'. Reverting it to 'default' or 'pylance' did the trick.
Just to inform if none of above works then
In my case i was using Kite extension in my VS code, I just disabled it and it worked. I think kite extension is blocking this feature.
OS: Linux Ubuntu 22.04
if you encountered with following error:
"The .NET Core SDK cannot be located. .NET Core debugging will not be enabled. Make sure the .NET Core SDK is installed and is on the path."
Normally Vscode remains unable to locate .Net sdk. need to set path manually.
sudo ln -s /snap/dotnet-sdk/current/dotnet /usr/local/bin/dotnet
restart omnisharp & restart vscode
No need to do anything. Just close and re-open. It will work.
I also faced similar problem. In my mac os cmnd + 'click' is used to 'go to definition' then it suddenly stoped working. If that is the case then please follow these steps:
restart vs code
restart pc
uninstall all extensions and reinstall again followed by a pc restart.
I had a similar issue with the extension C/C++ installed. I solved it by downloading an older version of the extension and upgrading to the last version. Somehow it solved the problem...
During a long compilation with Visual Studio 2005 (version 8.0.50727.762), I sometimes get the following error in several files in some project:
fatal error C1033: cannot open program database 'v:\temp\apprtctest\win32\release\vc80.pdb'
(The file mentioned is either vc80.pdb or vc80.idb in the project's temp dir.)
The next build of the same project succeeds. There is no other Visual Studio open that might access the same files.
This is a serious problem because it makes nightly compilation impossible.
It is possible that an antivirus or a similar program is touching the pdb file on write - an antivirus is the most likely suspect in this scenario. I'm afraid that I can only give you some general pointers, based on my past experience in setting nightly builds in our shop. Some of these may sound trivial, but I'm including them for the sake of completion.
First and foremost: make sure you start up with a clean slate. That is, force-delete the output directory of the build before you start your nightly.
If you have an antivirus, antispyware or other such programs on your nightly machine, consider removing them. If that's not an option, add your obj folder to the exclusion list of the program.
(optional) Consider using tools such as VCBuild or MSBuild as part of your nightly. I think it's better to use MSBuild if you're on a multicore machine. We use IncrediBuild for nightlies and MSBuild for releases, and never encountered the problem you describe.
If nothing else works, you can schedule a watchdog script a few hours after the build starts and check its status; if the build fails, the watchdog should restart it. This is an ugly hack, but it's better than nothing.
We've seen this a lot at my site too. This explanation, from Peter Kaufmann, seems to be the most plausible based on our setup:
When building a solution in Visual Studio 2005, you get errors like fatal error C1033: cannot open program database 'xxx\debug\vc80.pdb'. However, when running the build for a second time, it usually succeeds.
Reason: It's possible that two projects in the solution are writing their outputs to the same directory (e.g. 'xxx\debug'). If the maximum number of parallel project builds setting in Tools - Options, Projects and Solutions - Bild and Run is set to a value greater than 1, this means that two compiler threads could be trying to access the same files simultaneously, resulting in a file sharing conflict.
Solution: Check your project's settings and make sure no two projects are using the same directory for output, target or any kind of intermediate files. Or set the maximum number of parallel project builds setting to 1 for a quick workaround. I experienced this very problem while using the VS project files that came with the CLAPACK library.
UPDATE: There is a chance that Tortoise SVN accesses 'vc80.pdb', even if the file is not under versioning control, which could also result in the error described above (thanks to Liana for reporting this). However, I cannot confirm this, as I couldn't reproduce the problem after making sure different output directories are used for all projects.
Switch the debug info to C7 format instead of using the PDB.
Project Options -> C/C++ -> General -> Debug Information Format and set it to C7.
This generally happens when your previous attempts at debugging have not killed the debugger fully.
In Task manager look for a process called vcjit, kill it and try again.
Worst option restart visual studio, this should solve your problem.
I had this problem today and it turned out to be non-ansi characters in the path to the pdb that caused it.
I'm using windows through vmware, and my project was in a shared location: \vmware-host\Shared Folders\project
When I moved it to \Users\julian\project it resolved the issue.
I just ran into this problem. Visual studio was complaining about not being able to open vc100.pdb. I looked for open file handles to this file using procexp and found out that the process mspdbsrv had an open file handle to it. Killing this process fixed the issue and I was able to compile.
Try right click the excutable file of VS....and Properties->Compatibility-> Tick "Run this program in compatibilty mode for:" OFF........
I had a similar problem while working on a project which I had located in my Dropbox folder. I found that it would throw this error when the little "syncing" icon was going on the Dropbox icon in the system tray, since Dropbox was accessing the files to upload them to their server. When I waited to build until Dropbox finished syncing, it worked every time.
I have same problem C1033: cannot open program database,
Scenario
I have two dll's parent.dll and child.dll.I just attached child.dll project with visual studio debugger at the same time i am trying to build the parent.dll project,produces error C1033: cannot open program database
Solution
Stop debugging and kill the process attached with the debugger.Rebuild the project
This happens to me consistently if I Ctrl+Break to cancel a build (vs2015). There's some process that isn't shut down properly. I went on a rampage "End Tasking" ms/vs related processes (look for duplicates) and my build worked again. A restart would probably work too. As would moving to gnu binutils.
Annoyingly unlocker tools don't report any processes locking the file, windows doesn't let me delete the .pdb but I can rename it. My guess is two processes jump in at the same time during a build.
Are you using LinqToSql at all? Perhaps it is similar to the odd error I will experience occasionally as I asked in this question: What causes Visual Studio to fail to load an assembly incorrectly?
I changed my intermediate directory from:
%TEMP%\$(ProjectName)\$(Platform)\$(Configuration)\
to
C:\temp\$(ProjectName)\$(Platform)\$(Configuration)\
It works now. NO idea why.
In my case the problem was Google Drive: I forgot that the project was under a synced folder and G Drive probably locked that file. Pausing the sync didn't help since the error was throwed anyway.
Moving the project folder to another location not synced by Google Drive solved my issue.
Just to mention, at the beginning I thought it was my anti-virus, since when examinating the file using procexp it showed that the file was used by one of my anti-virus process. Excluding the folder project from my anti-virus scan didn't help in my case.
the simplest solution is "build one more time":
BuildConsole abc.sln /rebuild /cfg="release|Win32"
if %errorlevel% neq 0 (
BuildConsole abc.sln /cfg="release|Win32"
if %errorlevel% neq 0 (
rem process error
exit 1
)
)
I just ran into this problem and Google led me here. For me, it was Google Drive syncing my project files while I'm trying to run. Pausing Google Drive sync temporarily solved it, but I'd rather there was a way for Google Drive to keep its hands off while Visual Studio is doing its stuff. If anyone knows how I can configure that, please let me know
I do use to work in Eclipse cause i find it pretty good, but every day i am encountering this problem..."'Cleaning all projects has encountered a problem'. Errors occured during the build." when I hit the "clean projects" button. I have win 7 64 bit.
The only solution for this issue to work is to restart my computer. But I don't find it that good, because even if I restart my computer in the next 5 minutes when I compile a certain program it gets stuck again, it shows the same annoying message.
Please give me a solution to make this work. I wouldn't like to switch to visual studio...
It's hard to tell for sure, but your application might have some unreleased resources which 'clean' command can't remove. Did executable process terminate? If not, you whould have this error. You could try to remove binaries from build folder manually and see what file causes and error.
Basically, yesterday I could program in C++ and today I cannot.
I'm trying to write a simple hello world program in Eclipse Helios using the MinGW C/C++ compiler and I'm running into several problems, and I believe this one to be the root of it.
At first the program compiled and built, but when I tried to run it, an error dialogue said the FirstProject.exe file could not be found/does not exist in the launch configuration. However, I got no errors building and I could clearly see the binaries in Debug/FirstProject.exe in my project explorer. I tried refreshing my project explorer and alas, the file disappeared before my eyes.
I tried building the program again, and that's when I get this error:
c:/mingw/bin/../lib/gcc/mingw32/4.6.1/../../../../mingw32/bin/ld.exe: final link failed: No space left on device
I don't know what device it's talking about. I have more than 1TB left on this hard drive, so it can't be that. I tried emptying my %Temp% folder and recycling bin (suggestions I found trying to search for a solution for this problem) but to no avail.
It may be worth noting that C++ programs I have written in the past are still running. I'm very new to programming, so I don't know how much information you need, but I'll gladly add anything you need if you think you can help me out.
I just solved this on one of the computers at work which had the same issue when compiling through Codelite. Moving workspaces, rebooting, and reinstalling Codelite didn't fix the problem. I also checked permissions on the /temp folder which were fine.
It turns out there were permission issues/other issues with the disk. Running a disk check fixed a few issues on the disk and that allowed the program to compile. If this doesn't solve your issue you may also want to try disabling any anti-virus/spyware programs and try again.
I just solved this problem on my PC. Actually what the problem in my case was that my windows defender (or any antivirus in someone's case) was blocking ld.exe from accessing the protected folder that is the source code folder. You can correct this by going into the Virus and threat protection settings of your PC and then find there for blocked history. You will definitely find there a history record of that blockage. Then just go and allow on this device it. And boom 😁