I generated the .exe files by running 'make' for the c++ project g2o. However when I try executing them, a black window appears for a short time, but nothing else happens. Does it mean something went wrong when creating them? I generated them again using the source code from https://github.com/RainerKuemmerle/g2o, which resulted in the same problem.
Related
I'm creating a program in C++ on VS Code macOS. I have this line of code:
fileO.open("writing.txt", ios::app);
which is supposed to open a new .txt file and save whatever the user inputs into my program. However, VS Code is opening the file under the directory /Users/username instead of the directory where my program is located, which is /Users/username/Downloads/firstprogram/code.cpp. This seems to be a very simple problem but I cannot seem to find a correct answer for this. I only get results for non-relevent threads about directories in VS Code.
It is still able to access the same writing.txt file when I re-run my program and the .txt file still keeps the previous data. My program works 100% correctly because I coded it in a school-based linux ssh shell/editor and it was perfectly fine. This is a VS Code issue.
I have been unable to fix it despite following the VS Code macOS setup for C++. My launch.json files and tasks.json files have also been updated to match the files on the official VS Code website but I am still encountering issues related to the path of files being created. This is very confusing because I've never had this happen to python files that I create using programs, but it's occurring for my C++ programs. Any suggestions on what to do?
I'm following the gtkmm tutorial for gtkmm4 and I'm getting an odd error when I try to run my program. The program is an exact copy of the provided code, and it compiles successfully:
However, when I run the program it gives me a series of errors:
I'm not sure what to do at this point. I've tried googling, but I don't get anything helpful. I've check that the DLL in question does exist. Any advice is appreciated!
Edit: I ran the Dependency Walker program, and got some errors, not sure what this means though.
Edit2: I did some research on Dependency Walker, and it seems to have some known issues, so I also ran lucasg's "Dependencys" program, with this output. I'm still not really sure what this means, but it seems fine.
Edit3: I moved the 4 offending dll files into the build directory, and these are the new errors I'm getting. Its the same error, but now it points to the more local file.
Check your .exe file with Dependency Walker to see which issues there are loading the .dll files.
One possible cause could be that you're mixing 32-bit and 64-bit.
The issue was something to do with finding the correct DLLs. The solution, as outlined here, is to copy all the DLLs from C:\msys64\mingw64\bin into the build directory. Then, using ntldd or some other profiler, determine which DLLs are unnecessary and remove them.
I started programming in C++ using CLion IDE.
When I run the program inside the IDE it works. However, opening the .exe file outside the IDE generates a bunch of errors:
The code execution cannot proceed because libgcc_s_seh-1.dll was not found. Reinstalling the program may fix this problem.
Hitting OK pops the same message again with a different dll.
Why does this happen? What are the different ways to fix it? What is the best option?
You always need to ship any libraries your application is linked with along with your application. The libraries are just as much a part of your app as the code you wrote yourself. This includes your compilers runtime libraries (which you forgot in this case).
I can compile my program in Code::Blocks 13.12 (MingW (haven't tried other versions)) and run it within the IDE.
However, when I attempt to run the program outside the IDE I get
libgcc_s_jlj-1.dll missing
Reading around I have tried adding
-static-static-libgcc-static-libstdc++
to my linker settings (individually and I used the last two together) which doesn't work
If I copy the .dll files to the same folder as the .exe it presents
libstdc++-6.dll missing
to my attention. If I copy /that/ .dll too the program will run just fine; however, I'm not sure the legality of moving the .dll with my program, and I want distribute my program easily to others so the static option I read about seems preferable.
(side note: I shouldn't have this error so I'm curious as to what I'm doing wrong)
I'm getting ready to enter Ludum Dare this evening, and I'm getting really frustrated because I'm unable to build my project into a standalone .exe.
I feel like this question has been asked at least 100 times but none of the answers I'm finding are helping me out at all... I don't really understand what static linking is or how to do it, and that doesn't even seem like the solution to my problem; I don't mind if I'm shipping out a bunch of .dll files with my program, I just want the program to run on its own so I can submit it at the end of the competition.
Basically, my visual studio (2010 express) configuration follows exactly LazyFoo's tutorial on setting it up. Everything runs fine on both debug and release configurations when I start the program from visual studio, but when I navigate into the Debug or Release folders of the project and try to run the .exe, the programs break with an error about abort() being called, or they give me the error "X program has stopped working."
I'm including all of my DLLs in the same folder as the executables are being placed, and the game runs perfectly fine from inside VS, but I just can't seem how to figure out how to compile it as a standalone .exe (or even including a folder full of dlls) without it falling apart.
Can someone give me a pretty precise way to get this working? Any help would be great.
If you have an EXE, then your program is compiling. Most likely in debug mode, the program is running using a specific directory as the current working directory (CWD), but when you run it as standalone, the CWD is different.
The CWD affects both the DLL that can be loaded as well as the search of any file that uses a relative path (that is, not starting with a [back]slash). That is probably your problem: textures, graphics, configuration files, fonts...
My advise is to set the CWD in the debugging runs (there is an option for that) to be exactly the same than that of the EXE, that is the default when you run the EXE. Then you will be able to debug your crash.