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.
Related
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.
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.
I just started fooling around with SDL2 using Lazy Foo's tutorial and I'm having some issues. When building I get two errors:
cannot find lsdl
cannot find lsdlmain
Now... of course it can't find those because they are not in the lib folder I linked. I only have lsdl2main and lsdl2. I put the SDL2.dll in my project folder and did everything as Lazy Foo said, yet I still have this issue. I did manage to bypass this issue by copying the lsdl2 and lsdl2main from the lib folder and changing them to lsdl and lsdlmain. Now I have both lsdl/lsdlmain and lsdl2/lsdlmain ... even though they are the same libraries. I don't think this is ok, this is why I'm asking the question. What is the proper way to solve this? I read on lazy foo something about the compiler picking 32-bit libs over 64-bit , but I am using the 32-bit ones from the 32-bit folder, so I'm not sure if that is an issue.
The proper way is just use sdl2main and sdl2 instead of obsolete sdlmain and sdl in your linker options. Lazy Foo's tutorials are obsolete and obviously require some corrections if you intend to use SDL2 instead of SDL 1.x which is the version tutorials are based on.
This question is a year old but I hope this still helps someone struggling to find an answer. If you were following Lazy Foo's tutorial "setting up SDL" on Code Blocks, you might have accidentally opened his old tutorial via Google. http://lazyfoo.net/SDL_tutorials/ instead of http://lazyfoo.net/tutorials/SDL/ which has the updated instructions.
His old one shows that you have to fill out -lsdl and -lsdlmain on the Global Compiler's linker which is under Settings> Compiler.. > Linker Settings. Then you somehow opened his new tutorial which shows you to to fill -lSDL2main -lSDL2 under the Build option's linker.
Just check if your Global Compiler's linker or your Build Option's linker settings are correct. Setting -lSDL2main -lSDL2 flags on either one should work.
I'm totally spinning my wheels with getting a couple of 3rd party libraries to work with my c++ programs. I'm looking for some general advice (40,000 foot level) about the general steps that one needs to take when implementing libraries.
First, some specifics: I am using code::blocks in Windows as my IDE. I like this IDE and really don't want to switch to anything else if I don't have to (I've tried visual c++ and also some things in linux). The libraries that I am trying to use are GMP and crypto++.
OK. What I think I know is this: After downloading the library, I unzip the file to a folder. I've been unzipping directly to C:\ with each zip file extracted to its own folder (e.g. c:\cryptopp and c:\gmp). I think that the next step is to build the library, but this is where I get totally stuck. How is this done? There are no executable files among those extracted. From what I can tell, I believe that I do this in code::blocks, but I have no idea how?
Finally, assuming that I can get this done, which I believe creates the .lib files, the last step before actually using the library in my code, is to link into the library. This part, I believe that I understand.
So, my question is broad: do I understand this process overall? And if so, how do I go about building these libraries, if in fact that it the thing that I am missing.
Thanks very much for indulging my ignorance. I'm totally rudderless right now and despite hours and hours on google, I'm making no progress. Also, feel free to correct anything that I have stated as fact that is not correct. Thanks a lot!
Usually libraries have a special file called makefile in them, and are built with a utility called Make (or one of it's variations, whatever works uder windows).
Usually all you have to do is to run Make in the directory where you have unpacked the source files, and it will do the rest itself.
If those libraries you mention (GMP and crypto++; disclaimer: I'm not familiar with either of them) don't have project files for code::blocks then you may still be able to compile them under Windows with MinGW.
If you have installed MinGW you use the MinGW shell to navigate to the appropriate directories which would be /c/cryptopp/ and /c/gmp in your examples - The MinGW shell works like a Unix shell, and has different naming conventions.
Then you need to compile the libraries. Check whether there's a Makefile in those directories, if there isn't you can check whether there's a configure script, which will generate the Makefile. If you have the Makefile you can type make which will compile the libraries with MinGW's port of the GCC compiler.
When the compilation is complete you should have a library in the form of a .a file (say libcryptopp.a) that you can link to your project. In code::blocks you would set the linker path (the -L command line option in GCC) to C:\cryptopp\bin or wherever the library has been compiled, and then add libcryptopp.a to the list of libraries you want to link (this is associated with the -l option in GCC). The convention is to leave out the lib prefix and the .a extension, so you would just add cryptopp to your library list. In the end your linker options should look like -LC:\cryptopp\bin -lcryptopp along with the
Also, to be able to use the libraries you need to add the path to the headers directory to the include path of your project. This is associated to the -I command line option in GCC, so your compiler's command line options would have something like -IC:\cryptopp\include somewhere.
Of course, all of the above assumes that you use code::blocks with GCC. If you're using it with VisualC++ then the principles are the same, but the specific steps differ.
I am currently building a rather large application, using cmake to generate cross platform build scripts. During this process of putting together the cmake build scripts, I have discovered the pain of gcc link line ordering.
The basic issues is that including static libraries in the wrong order leads to unused library symbols being thrown away that then cannot be found by subsequent dependent libraries.
Thus, I am in the situation where cmake generates a visual studios build system that compiles just fine, but the unix makefiles throw all kinds of "undefined symbol" errors. I have figured out a work around for this - in the add_executable command, I am including the static libraries twice.
My hope is that there is a more standard/better way to deal with this issue. Being that I am not the only developer, and that the majority of regular development is done in windows, I really want a link-order agnostic CMake script. The windows developers just don't deal with this link order issue. On top of that, figuring out the correct order would be very difficult - I do not have that information readily available and there are a lot of static libraries (70 or so).
After searching the internet, I did learn about the -static and -dynamic flags, but getting CMake to include them is non-obvious and gcc complains about not being able to find the dynamic libraries.
Anyway, I welcome suggestions on how to do the right thing.
Did you try disabling the strip? Maybe with something like cmake -DCMAKE_STRIP=/bin/true ..? Maybe that will stop the symbols being thrown out.
I think this is less of a CMake issue, and more of a GCC behavior. This question/answer should help out a bit:
Linker order in GCC
You will have to bite the bullet and modify your CMakeLists.txt files to link properly on Linux. Since the Windows developers don't care, you shouldn't disturb them.
Best,
-dan