Just a nooby question, but I was wondering that every time I use g++ from MinGW on a Windows 8.1 command prompt, do I always have to change directories to compile it? This gets very tedious for me at least because I like to keep different assignments in folders, and cd'ing all of that address kind of gets me a little annoyed.
I've seen my professor on his Linux machine that he doesn't need to change directories and just compiles the program as he finishes writing the program.
Right now my Environment Variables are set to ...;C:\MinGW\bin;%PATH% Do I need to add anything more to this or do I have to move all my files into a certain destination? I've also tried Cygwin, but that keeps giving me errors and the other answers on this site are very confusing. In fact every answer on this site has been kind of hard to comprehend... is there a dictionary that I should be looking before I read one of the posts?
Sorry!
Related
I am trying to use EXECUTE_COMMAND_LINE (Fortran) in Code::Blocks to start a program through a shortcut with the Windows command prompt. I have checked the path and the syntax several times, and everything is correct, however whenever I compile and run the code, when the script reaches this command I get an error saying that "The specified path does not exist. Check the path and then try again.".
Even more peculiar is the fact that, using the exact same command within the EXECUTE_COMMAND_LINE directly in the command prompt successfully launches the application with no problems whatsoever.
The command I use is the following:
CALL EXECUTE_COMMAND_LINE("start C:\Users\dimpa\Desktop\Giannako\Optimization\VBA\SLDA.lnk")
I run Windows 10, Code::Blocks 20.03 and have the MinGW compiler for Fortran.
Have also used SYSTEM with exactly the same results. Also, if it is to any use helping me figure out what is going on, this command works just fine:
CALL EXECUTE_COMMAND_LINE("start C:\Users\dimpa\Desktop\Giannako\Optimization\VBA")
Opening the folder VBA to my File Explorer. The problem seems to be related with opening the shortcut of the application. Further more, opening files located in dimpa\Appdata folder (original .exe, not the shortcut) seems to be working even through the IDE, where anything in Program files is inaccessible.
Thanks in advance.
Cheers, after endless experimentation, I seem to have found a workaround.
The problem was revolving around spaces being included in the path of the original program of the shortcut in use. Apparently the compiler isn't fond of executing shortcuts, which might initially not contain spaces in the initial path, but when redirected to the original program can run into all sorts of things.
The shortcut that I was trying to execute contained a path leading into Program Files and opened an additional addon to be executed in the aforementioned program ("/m"). After realizing that trying to run a shortcut with a 150 string length target could complicate things, I directly entered the target of the shortcut into the Windows cmd, which worked perfectly fine and was much more easier to dissect and be examined in order to properly write the code:
CALL SYSTEM(""Full Path to Program" "/m" "Full Path to Addon"")
Hope this helps someone facing similar issues!
Recently I obtained a solution which has been created on another person's machine. I have been banging my head into the monitor in the past 2 days trying to fully migrate the solution to my machine. I have been manually changing the directory addresses of the solution and have not been able to compile the solution although I think I have corrected more than 100 paths as of now. Here's my first attempts to migrate the solution to my machine and resolve the issue of not being able to open any of the files.
Now I can open all the files in each project on my machine (after manually changing their paths). However, I am still getting the same errors and I'm not able to compile the project. Below is a picture of the errors I'm getting:
And here's the output log when trying to compile the project. So I wonder, can someone give me some advise on how I should go about doing the whole process automatically? In the output log I see there is a F:\Virtual ... path which indicates the solution been created on a virtual machine. However, I am not using a virtual machine and am not able to find the file file containing that path (F:...) so that I can change it to the correct one (I even do not know what the correct one should be since I am not using a VM).
If you are not able to help me through the description I gave or the output log file, you can download the whole solution from here and then give me some instructions on how I should go about compiling and using it. I really appreciate your help.
Chances are that someone went rogue on the project file, because normally all paths are defined in a way that is relative to the project or solution, making them portable.
In order to fix this, I see two options, either set up the project files from scratch or keep on hacking on them until they compile. Whichever path you take, keep in mind that VS supports placeholders like $(SolutionDir) you can refer to when setting up paths. If that doesn't work, please try to extract a minimal example.
Also, make sure you have a version control system set up, so you can retrace your steps. This should be standard in any software development, but considering the state of the project I wouldn't be surprised to find other, hairy places there.
I've been running and compiling a program on my Windows 7 64-bit machine for several months now, but recently I had to change several VC project settings of the static libs that it uses and now the generated executable file requires me to run it in "Windows XP Compatibility Mode".
Compiled on Windows7 64-bit machine with Visual Studio 2010 SP1
The program I am generating is being built in Win32, debug mode.
The static lib projects specify Target Machine /X86.
When I run the program from the debugger, it start up and runs, however if running via the windows icon, it requires XP compatibility mode.
When trying to start outside of the debugger the EXE shows up in task manager for a second then goes away.
I've tried using Microsoft Application Verifier on it, however I don't know what to look for in the output.
I've been unable to find any details on how to troubleshoot this issue so if anyone has any ways if finding what could be causing this recent Compatibility Mode requirement I'd love to hear how it was fixed.
I have the source/projects/solutions for the majority of the static libs that I link against, as well as the exe file generated, however some of the external dependencies I only have the .lib,.dll, and .h files for. This means I can change (most) of the project settings for the dependencies if neccessary, but I need to know which ones to look for.
Thanks
To be honest, don't be afraid to make another project and copy the code files, even if it's 5 projects. You need to cut the problem in half. If it works with the new projects then it's the project files, if not, it's the code. Making projects isn't that hard really, though I'm sure a source of much consternation and something people avoid. If its the projects you can diff the files and see what happened by process of elimination. If you are really worried, copy the entire solution to another folder; always make backups.
The problem is that you probably won't be able to hoist enough information up to us to get a meaningful answer unless get lucky, and all the answers will be shots in the dark.
So I'm goign to take this question as "this happens, what can I do about it". The strategy above will get you out of it, if this used to work before. This exercise will arm you for the future and will be more productive in the long term. Go look at UAC and manifest files, aka Vista+ difference tht dramatically changes load and run behaviour (Linker Commands, Vista Migration Guide) if you need one thing to look at, but try the above process.
----
Other generic things to try:
1) another machine
2) another install of VS
3) a simple project with one window that does nothing to prove everything else in your tool chain and environment is ok.
4) planting message boxes along the code path with different messages so you know where its crapping out.
5) turing on pdb in release and runnign outside of debugger. If craps out, then try debugging and see if still craps out, but you get to see where.
6) assume that your code is unstable and you were getting lucky when it used to work. (this one is no fun). Many times things work in debug and not in release due to mem layout being different. If your progam is large you can find creative ways to use #if's whatever to elimitate code from running while haivng the whole thing still load. You can find the code that causes the bad behaviour.
7) turn off UAC and error reporting if its on, see if changes.
8) go find the "run without debugging" menu button in Visual Studio, so you don't have to go run it with the icon. That's an accident waiting to happen, and eliminates one more environmental difference. It looks like the run with debugging button, but it's hollow, a plain green triangle. It's under debug menu set. My oppinion is that it has done more harm than good to not have that on the bar by default as its confused many many people to think launching wiht VS means always using the debugger.
and so on....
Working in C++ MSVS2008, I've been having increasingly irritating problems: Breakpoints executing on the wrong line, not catching, etc. It's a really large workspace with thousands of files, so I "put up with it".
I went through the "standard" stuff (clean, "deep" clean, manually delete *.idb, *.pdb, *il*, etc.) It didn't fix the "breakpoint-on-wrong-line" problem, but things at least compiled and I could run/debug.
THEN, (for unrelated reasons), I created a command-line program that issued a compile-one-CPP-to-OBJ command, and got a strange error:
cl : Command line error D8037 : cannot create temporary il file; clean temp directory of old il files
I never heard of that before, so a web search got me to the Microsoft site that details the error:
http://msdn.microsoft.com/en-us/library/bb385201(v=VS.90).aspx
Um, Huh? In my system TMP dir, there were apparently too many _CL_hhhhhhhh.ss files. Searching, yes, I had exactly 6,063 of these files in that directory, going back about one year.
I've never heard of these files before ("temporary compiler files"). Searching the Microsoft site shows that this error is possible in at least MSVS 2005, 2008, 2010. Being "temp" files, I assume there is some kind of "cleanup" or "recycle" algorithm?
How many _CL_hhhhhhhh.ss files is the limit? (I had this error under one condition at 6,063.)
Why do I see this error when I execute a "compile" from within an EXE, and not from within the MSVS IDE? (I don't see this error when I execute the "compile" directly from the command line either.)
Should I be doing "maintenance" on my development machine by cleaning up files like these periodically?
What other "cruft" files do I need to think about finding-and-removing?
As an aside, I'm aware that the MSVS project GUIDs are cached in the registry so that the IDE can "find" project files that are manually moved around to "repair" links/dependencies with other project files. I'd like to know how to clean out those too, if anybody has a suggestion.
This does lead to the ultimate question of, "What kinds of hidden cruft accumulates from using MSVS on a development machine?"
Win7/64, C++ MSVS 2008, NTFS
I'm not sure if the particular file you were having problems with was fairly large (greater than 10,000 lines), but I've had the same issue of breakpoints being on the wrong lines several times under that circumstance in MSVS2008. The solution that worked for me (and improved the readability of the code) was to group a few of the functions logically into a class/namespace and put them into a new file.
cl.exe when launched via CreateProcess does not seem to have write permissions addresses your second question. Why do you only see it when launched from within an exe?
It's most likely that cl.exe is failing elsewhere. If you use Process Monitor, it will give you a good idea on all the system calls made by cl.exe and what failed.
In my case, I was overriding the environment variables when calling CreateProcess and in that process ended up resetting SystemRoot environment variable. cl.exe uses it to resolve paths for some system dlls and as a result never ended up finding the dll.
The short term fix was to add "SystemRoot=c:\windows" to the environment settings I was passing into CreateProcess.
The right long term fix is the get the environment variables, parse them and only modify/append as required and pass that whole environment variables block to CreateProcess. That way, cl.exe launched via CreateProcess inherits the environment variables that your exe launched with.
hey the title pretty much says it all. i have been trying different methods from internet sources, but whenever i try something goes wrong..this is where i got Box2D
in cMake, i get a bunch of errors when building it(i was going through the steps in the readme.txt, but onfortunately, theyre for Visual C++...)
so im wondering hot to set this up as i guess a library (.lib or .a) and use it in my project(my friend passed me his library and when i loaded it in and tried #includeing the box2D headers, they didnt read at all(i got a list of undefined errors) also his box2d was i believe made for linux/unix so i think thats the reason...)
if anyone can help provide some steps that would be nice.
thanks for reading.
Assumptions:
You have installed cmake.
You have installed Code::Blocks/MinGW to C:\codeblocks.
You have downloaded Box2D and extracted it to C:\Box2D_v2.1.2.
If any of those are wrong, modify the paths to match what you have.
Start->Run->cmd.
Navigate to the Box2D "Build" folder:
cd C:\Box2D_v2.1.2\Box2D\Build
Create the makefiles:
cmake -G "MinGW Makefiles" ..
Do it:
mingw32-make
This will throw some warnings, but should work almost completely. Then, near the end, it will error trying to compile the Testbed. AFAIK, there is no way to compile the Testbed using MinGW (you have to use Visual Studio, I believe). Luckily, an .exe of it is available on the Box2D site.
In the Box2D\Build\Box2D folder, there should now be a file called libBox2D.a. Copy this file into C:\codeblocks\mingw\lib.
Copy the Box2D\Box2D folder (the one containing Box2D.h) into C:\codeblocks\mingw\include.
[Thus, after this step, you should have a file C:\codeblocks\mingw\include\Box2D\Box2d.h, and NOT C:\codeblocks\mingw\include\Box2d.h]
And that's it. You should be able to compile and run the "Hello Box2D" example. Don't forget to link to the library.
[EDIT]
From the looks of your error, I'm going to guess that your MinGW Path environment variable is not setup correctly. Which is unusual, since when you install Code::Blocks/MinGW it usually sets it for you, I believe.
Anyway, (these steps may vary slightly depending on your version of Windows):
Right-click on "[My] Computer"-> Properties -> Advanced System Settings
Click "Environment Variables"
Depending on which Windows you have, you may see User Variables and System Variables, or it may be just one group (I can't remember the name). Anyway, create a new System Environment Variable called MINGDIR, with the value C:\codeblocks\mingw or wherever you installed it to. Then, find the variable called Path (or PATH) and append this to the end: C:\codeblocks\mingw\bin. Put a semicolon at the end of the previous entry, and do not use a space.
Also make sure that C:\CMake\bin is present in either the System Variable called Path, or the user variable called Path. If not, append it to the end.
I think that's it.