In CodeBlocks with compiler GCC, libgcc_s_sjlj_1.dll is missing - c++

I'm trying to run my first SFML program using Code::Blocks 16.01. It compiles, but then warns me that libgcc_s_sjlj-1.dll is missing. My compiler is GCC 4.8.1-4. Other similar questions, such as: "libgcc_s_sjlj-1.dll" is missing, have said to use linker flags, so I included -static-libgcc and -static-libstdc++as linker flags, but that didn't work.
The MinGW bin is included in my path. I have copied the .dlls into the directory with my executable. I looked in the actual bin and the .dll isn't even actually there, so I have reinstalled MinGW a couple times.
One thing I have not done is download the .dll itself which I have read is not a good idea. I'm not sure how to get past this error.

Yes, it's a problem about dynamic linking and static linking.
I met this confusion several months ago, when I build and run my little code snippet, the computer warned me that "stdc++-6.dll" was missing, so I tried to google and download the .dll file(which should be located in c:\windows\system32), but it didn't work, because when I run my program next, it warns that "libgcc_s_sjlj-1.dll is missing".
I didn't download the file, but I make some "extra settings" like you, I included -static-libgcc and -static-libstdc++ as linker flags, and it didn't work either, then I include -static.
Then my codes work so well. And I wish it could help you.
P.S.I have written an article in Chinese to talk about this problem.

Related

Cross Compiling from Linux-Windows, stdio has undefined references (to __imp___acrt_iob_func)

As the title says, I've been trying to cross compile a fairly large project with quite a few dependencies (both static and dynamic libraries). I've cross compiled every dependency successfully using MinGW-w64, set the include & library search paths to their MinGW counterparts (/usr/x86_64-w64-mingw32/lib & include), and yet on the linking step MinGW throws out an error for each call of printf (with stdio.h included, of course). The errors are as follows:
/usr/bin/x86_64-w64-mingw32-ld: ./obj/XXXX.o:/usr/share/mingw-w64/include/stdio.h:352: undefined reference to `__imp___acrt_iob_func'
(Where "XXXX" is a file name from my project)
This error is repeated the exact same (with the exception of the object file name). The command for linking looks like this:
/usr/bin/x86_64-w64-mingw32-g++ -o bin/ReleaseWin/Project #[file with object file names] -L. -L/usr/x86_64-w64-mingw32/lib/ [linking some dependencies (boost, openGL, SDL2, etc.)...] -m64 -flto
I've searched for a solution (or even someone with the same problem) to no avail. I've never been well-versed in linking any more than regular libraries, so if you need more information just ask.
Thanks in advance :)
Extra info:
This project has been cross compiled (from Linux to Windows) successfully before, and I haven't added/removed any dependencies since.
My MinGW-w64 version is 7.0.0
So, I apt-get purge'd mingw-w64 and mingw-w64-common, reinstalled just mingw-w64, and now it's working...
This might have something to do with the fact that I followed the issue that Richard Critten commented with (thanks!), which led me to try downloading and manually copy/pasting headers and CRT (mingw-w64-x86_64-headers-git-... & mingw-w64-x86_64-crt-git) from the MSYS2 repository. That didn't work right away (probably because I screwed up and used the 5.0.0 versions instead of my version), but it seems to have done something.
Therefore, for those who stumble upon this issue,
Try a re-install of MinGW (of course),
Try manually adding the CRT and headers from the link I supplied, and if that still doesn't work,
Try re-installing MinGW again. I'm not super familiar with apt, so I don't know if adding the CRT and headers actually changed how it installed MinGW, but it's worth a shot I guess.
Update: I had this exact same problem on another system. Simply reinstalling MinGW fixed it, so it seems like maybe there was some sort of issue with the files? It's possible that updating from an earlier version messed with things. Moral of the story: even if you think your files are good, a reinstall can't hurt.

Cannot find -lfreetype (SFML static linking)

I'm trying to statically link SFML, which requires linking all other dependencies. On the SFML tutorial page it states that all dependencies are provided along side it, but I genuinly couldn't figure out any way to link them. Other dependencies seem to work just fine (or they just don't produce linker errors yet). I also tried manually downloading freetype, building it, but that just left me in a bigger mess of files, and as a beginner, I really can't follow anything what's going on. My "Link libraries" look like this:
And I tried putting the directory of the header files (I could only find the header files, nothing else, no .a or .so files, not sure if that's the problem) in various places in the search directories.
Closest thing to my problem I found was this, but I really couldn't get anything out of this...
P.S. I'm on Windows, using Code::Blocks, GCC 7.3.0, custom built SFML with CMake for my compiler aswell. Unless I missed something in tutorials, I don't think I missed anything. Without static linking, everything worked fine. I didn't forget SFML_STATIC in #defines either. I don't know what else to add, if there is something missing, please tell me.
I'm at a loss for a couple of days here, any help would be appreciated, even if it's some harsh critique because of missing a simple detail :P
The solution to this specific problem for me was simply rebuilding SFML with CMake again, because for some reason the install path (Program Files x86\SFML\..) wasn't actually created, and that's where all the .a files were. Including those in the search directories fixed the cannot find -lfreetype problem.

problems with running c++-programs

I wrote a c++-program including <iostream> to use std::cout and std::cin. I compiled it with the g++ compiler (GNU compiler collection) on Windows 10 using MinGW. When I run the program with the run-terminal of MinGW it works but when I try to run it with cmd.exe or open it in Windows Explorer I get this Error:
"The program cannot be run because libstdc++-6.dll is missing. Please reinstall the program to solve the problem."
Because I didn´t install my program, I tried to install libstdc++-6.dll. I downloaded the file in zip-format but I don´t know where to unpack. Has this file to be in system32? Do I have another problem? Can anyone help me to solve it? I already read a simliar question and its answers but -static-libgcc -static-libstdc++ didn´t work.
This is a repetition of this question libstdc++-6.dll not found according to #kerrek-sb do this
If you are using MingW to compile C++ code on Windows, you may like to add the options -static-libgcc and -static-libstdc++ to link the C and C++ standard libraries statically and thus remove the need to carry around any separate copies of those. Version management of libraries is a pain in Windows, so I've found this approach the quickest and cleanest solution to creating Windows binaries.
You might want to compile your code with g++ and the options -static-libgcc and -static-libstdc++ so to link the C and C++ standard libraries statically. As a result you don't have to install libraries in your Windows path and you can carry around the executable on other systems.

Can't compile glew when using it via my own library : CodeLite

I have edited out a lot of my original situation to try keep things simple; it can be seen in the revisions.
Basically I have been following a tutorial in which a game engine is being created.
Most of the code has been separated into its own CodeLite project and successfully compiled into a static library (libbengine.a using mingw32 via TDM-GCC-32).
(For the record, the code compiled fine before separation)
Back in the main game code (main.cpp, etc) the compiler knows the relevant include and lib directories and compilation can at least locate the necessary headers and lib.
However, I get this error: undefined reference to '__glewCreateProgram'
Any ideas as to what is getting lost in translation (so-to-speak)?
I have been reading around all over the place; researching compilation, static libraries, ar.exe, but am having no luck (I am still looking).
If you want any more pertinent information, I will happily provide it; for now I shan't clog up the post any further.
Cheers
To give a basic idea of the error in CodeLite:
Main project linker settings:
bengine project linker settings (compiled as static lib.a):
It seems the problem was solely with linking order. As can be seen in the second image in my question (Main linker setting) - "Bengine" should have been at the top of the list, not the bottom.
This may be mingw32 specific; I am not sure.
Well, after all those hours, I feel somewhat foolish...
At least I have learned some things along the way.

g++ linking issues: undefined reference to functions

I used CMake and Visual C++ to build the HyDE library. Then, still in VC++, I was able to successfully create code and build an executable that links into HyDE.lib and the HyDE header files.
I then discovered that in order to work with others at my company, it would be preferable to develop in Eclipse CDT. Knowing very little about Eclipse CDT, I created a default hello world project, deleted the code and then dumped in all of my code into the src folder. Then I attempted to change the includes and lib path and libs to mirror what had worked in VC++. At this point everything seems to compile, but I get an error in linking:
/cygdrive/c/EclipseWorkspace/425HyDE/Debug/../src/FS5HyDE.cpp:16: undefined reference to `HyDEAPI::HyDE::HyDE(HyDESystemModel::SystemModel*, bool)'
(There are many more errors like this, all referring to HyDE methods.) Here is what is being run at the command line:
g++ -L"C:\Progra~1\boost\boost_1_42\lib" -L"C:\EclipseWorkspace\HyDE" -o"425HyDE.exe" ./src/Adapter_FS5HyDE.o ./src/EPSCommands.o ./src/EPSCurrentSensor.o ./src/EPSFault.o ./src/FS5HyDE.o ./src/HyDEObservation.o ./src/MCDH.o ./src/MCDH_Module.o ./src/PDBComponent.o ./src/PowerSystem.o ./src/Program.o ./src/SSPCComponent.o ./src/Telemetry.o ./src/TelemetryReport.o -l:libboost_thread-vc90-mt-gd-1_42.lib -lHyDE
This is definitely not a library ordering problem because I've the other ordering as well (there are only two). Is it possible that there is a problem with compiling HyDE.lib in VC++ (which uses a Windows compiler) and compiling my program with g++? Could there be a problem in the way that Eclipse CDT is autogen'ing the makefiles? Any other ideas?
(Note: there appear to be plenty of others questions on SO with similar problems, but after reading through them I have yet to find one that addresses my problem.)
Classic missing symbol error. Which source file defines:
HyDEAPI::HyDE::HyDE(HyDESystemModel::SystemModel*, bool)' ?
Was this file added to the compilation? Can you spot it on the command line you pasted?
If this symbol belongs to an external library, after adding the directory path with -L , you could add the name of the specific library you want to link with your program using -l.
I'm going to suggest that you try to add to the compilation command the directory path to HyDE.lib, followed immediately by the library name, like this:
-L"C:\path_to_hyde_library" -l:HyDE.lib
and then tell us what happened.
Solution: Since the HyDE library was compiled with the Visual Studios compiler and I'm attempting to build the code that links to it with the Cygwin toolchain the two compilers use different name mangling schemes so that the latter linker can not find the expected symbols in the HyDE library. The only solution that I've found is to recompile the HyDE library with the Cygwin toolchain or compile the new code with whatever compiler Visual Studios is using. (grumble grumble)
./src/FS5HyDE.o and ./src/HyDEObservation.o should be the latest parameter if other object files (*.o files) need them, it means that the most needed object files should be appeared as last as possible in the parameters list.