SFML_USE_STATIC_STD_LIBS

[Strikerklm96]

I am using Code::Blocks MinGW, and I want to better understand what the implications are of enabling that command when generating my libraries.

Here is my understanding, please correct it, and hopefully add to my understanding. 

Dynamic Linking SFML
The option is not valid for this choice, so it is off.
If I link SFML dynamically, I will need libgcc_s_xxx-1.dll and or libstdc++-6.dll. But I just ran a simple test program and did not need either of those. Under what circumstances DO i need them when doing everything dynamically. Certain function calls/class instantiations?

Static Linking SFML
I turn the option off, so I am NOT statically linking the std libs.
If I link SFML statically, I will need libgcc_s_xxx-1.dll and or libstdc++-6.dll. But I just ran a simple test again, and did not need either of those while linking SFML statically. Under what circumstances DO i need them when doing SFML statically, but std non static. Are those conditions the same as Dynamic Linking SFML?

Extra Static Linking SFML
I turn the option on.
I link SFML statically, and tell those SFML libs that I will be linking the STD libs statically. But I just ran a simple test again, and did not link either of the std libs in the project, and it worked. Do I need to link them in the same conditions as the previous two?
In the situations where I do need to link them statically, do I need the libs from the SFML\SFML-2.1\extlibs\libs-mingw\x86 directory? My computer is x86. Which libraries would I need to link? All of them?


openal32 and libsndfile have .a and .dll versions. Is .a the static library version that I can link statically?
"If you are using the sfml-audio module (either statically or dynamically), you must also copy the DLLs of the external libraries needed by it, which are libsndfile-1.dll and OpenAL32.dll"
Everything could be linked statically, but I would still need these two dll files?

Thanks

[Laurent]

Static vs dynamic linking the standard library is usually a concern when memory allocations and deallocations are shared across modules. In case you link it statically, each module has its own memory heap, thus calling new/malloc in one module and delete/free in another results in undefined behaviour. In C++ this can happen implicitly, for example if one of the module's functions returns a std::vector or takes a std::string: memory is allocated on user side, and deallocated in the module. If every module uses the same standard library DLL, then they all share the same memory heap and there's no problem.

If you're using a TDM-gcc build, you'll notice that they chose to link the standard libraries statically by default, and SFML didn't (doesn't?) handle this specificity in its build process.
You can check this issue for a complete discussion about this subject, and what we chose to do (or not) in SFML.

openal32 and libsndfile have .a and .dll versions. Is .a the static library version that I can link statically?

Nop, they are just import libraries. Basically, they tell the linker that the functions are located in the DLL files (on Windows, unlike other OSes, you can't give a DLL file directly to a C/C++ linker, you always need intermediate import libraries).

[Nexus]

You're mixing things... At first, linking SFML and linking the standard library are independent options. However, linking the standard library statically and linking SFML dynamically is a bad combination, because then both SFML and your project will have their own version of the CRT, which leads to runtime problems.

If you link the standard library dynamically, you do need the corresponding DLLs. Don't test on your computer where they are installed in a directory that is registered as PATH environment variable (and is thus used implicitly). Test on a different computer with no development environment whatsoever, not even redistributed DLLs. Then you'll see that the program won't work without standard library and C runtime DLLs.

You cannot link OpenAL and libsndfile statically for licensing reasons.

[eXpl0it3r]

I assume "using Code::Blocks MinGW" means that you're using a variation of the TDM builds. If so then, yeah this is exactly why I advise anyone to dump TDM builds and use something like the MinGW Builds.

TDM linking is broken by design. There are some "points" that I can understand why TDragon would've gone this way, but these points don't justify breaking the standard way of linking. Every build system that hasn't adapted itself to the TDM builds will be broken. I tried to talk to the Code::Blocks people, but they just seem to not care or understand at all.

TDM links the runtime libs statically by default, so if you don't specify anything, the runtime libs will be statically link. Now with every GCC version you'd have to specify -static (or static-libstdc++ -static-libgcc) to link the runtime libs statically. With the TDM builds specifying -static will generate an error and fail to build. Instead TDragon added -shared-libstdc++ -shared-libgcc in case one wants to link the runtime libs dynamically regardless.
Since no make script or any other GCC based build system works that way, they are essentially all broken for the TDM compiler, showing again how stupid such a change was...

Since the Code::Blocks guys didn't seem like using a proper MinGW compiler, I've added support for the TDM compilers with SFML. As such specifying the SFML_USE_STATIC_STD_LIBS will link the runtime libs statically regardless whether it's a proper MinGW version or the broken TDM and of course it will link them dynamically if the flag hasn't been set.

If you want to check against a simple example you need to add the flags as I've explained above. Also keep in mind that if your MinGW/bin directory is in PATH, the runtime lib DLLs will be found automatically. So if you want to test whether it's link statically or not, you need to remove the MinGW/bin directory from PATH and run the application directly (and not from within Code::Blocks).

[Strikerklm96]

Thanks for all your answers!
I read that article you linked eXpl0it3r, and found it very interesting. Although I can't understand what all of it meant, I agreed with your last post, about it not really being a GCC compiler anymore, considering its usage changed.

How can I tell if I am using TDM or standard GCC? Do I have other options? I like to use Code::Blocks in Windows. Would you recommend getting standard GCC?


Anyway, what would be a good place to learn more about these topics? In particular, I don't feel like I understand:
What MinGW is.
What SJLJ and DW2 are and how they are different.
gcc, g++,
What libgcc_s_xxx-1.dll and libstdc++-6.dll are and why I need them.
The legality in software, GPL.
TDragon talks about linking statically to avoid legal issues?

Once again, I don't expect anyone to answer this variety of topics, but what is a good website that can give me this information? Im a Junior in CS, but my classes have never really gone over this stuff, but I know it's important, and I'm tired of having mystery compatibility errors that are beyond my knowledge.

[eXpl0it3r]

How can I tell if I am using TDM or standard GCC?

Open the command line and enter g++ -v, it will show you how GCC was configured and what version you have (e.g. TDM-2.0).

Do I have other options? I like to use Code::Blocks in Windows. Would you recommend getting standard GCC?

Any other build based on the MinGW-w64 project should do it. I use "MinGW Builds" they are always uptodate and offer multiple configurations.

Anyway, what would be a good place to learn more about these topics?

Rather dry but informative would be the GCC manual. And then there's also Google.

What MinGW is.
What SJLJ and DW2 are and how they are different.
gcc, g++,
What libgcc_s_xxx-1.dll and libstdc++-6.dll are and why I need them.
The legality in software, GPL.
TDragon talks about linking statically to avoid legal issues?

MinGW is a project which brought GCC to Windows, so it's essentially GCC for Windows, but don't use the original MinGW project! Due to politics it has lost most of the maintainers, thus it's always behind and has lots of issues. Instead there's the MinGW-w64 project which is the standard choice now. Keep in mind the w64 doesn't mean it's just an x64 compiler, they offer both.

SJLJ, DW2 or SEH are exception models, meaning different implementation on how exceptions are handled/rewinded. You can easily google a bit on this topic.

gcc vs g++ will be better explained in the manual.

libgcc and libstdc++ are the two runtime libs. libstdc++ is an implementation of the STL defined in the standard. Not sure what libgcc exactly does though.

Here are some resources regarding how the GPL prohibits the casual distribution (i.e. without accompanying source code) of libgcc and libstdc++ DLLs.

http://mingw.5.n7.nabble.com/no-subject-td16287.html - Eli Zaretskii's initial report of RMS' answer to the question of libgcc & friends DLL distribution.
http://mingw.5.n7.nabble.com/Why-libintl-is-linked-to-libgcc-s-dw2-td30981.html - Further conversation about the potential pitfalls.
http://gcc.gnu.org/ml/gcc/2004-06/threads.html#01123 - Conversation on GCC ML - thread "Licensing of libgcc and libstdc++ as shared libraries".
http://www.qtcentre.org/archive/index.php/t-28342.html - An example of casual users encouraging each other to break the law through lack of information.

As a distributor of GCC itself, I am able and willing to fully comply with the distribution requirements of its licenses. However, I find it ethically preferable to alter my GCC build so that its default behavior discourages casual users from breaking the law, rather than encouraging them. This approach has been somewhat difficult and has certainly earned disapproval from you and others.

The problem in short is that, if you link libstdc++ dynamically (i.e. when you have to distribute the DLL), you might have to distribute the source code of libstdc++ as well.
While he's right (I think) nobody really cares that much, especially the GCC guys regarding small projects. The only time it could/might really matter is with big game that generate a lot of money, but even then I doubt anyone would start a lawsuit. The licensing mess with the GCC runtime lib is also the reason why Clang created it's own version, with a better license.