Shared SFML Libs + Static Runtime Libs?

[Daddi]

Hi guys,
I ran into the following problem.

I compiled SFML myself using MinGW Builds 4.8.1 and build shared libs. If I try to use them in my project and simultaneously try to use -static or -static-libgcc -static-libstdc++ my executable gets bigger by including libgcc and libstd++ (and pthreads on -static) but is still asking for the libgcc dll.

I think its because the SFML .dlls are linked dynamically to libstdc++ and libgcc. That didn't happen while I used TDM, probably because TDM linked libgcc/stdc++ statically although SFML_USE_STATIC_STD_LIBS was unchecked (as it has to be for shared sfml libs).

What did I do wrong? What can I change?

Greetings
Patrick

[eXpl0it3r]

If you build dynamic SFML libs, then they will link dynamically against the runtime libs as well. Until recently SFML didn't support TDM properly, thus linking the runtime libs statically even though one told CMake not to do so.
Building SFML newly from source with TDM should have the same effect now.

If you want static, I suggest you simply build SFML static as well.

[Daddi]

Does that mean there are only the two options of linking everything dynamically or everything static? I can't link libstdc++ and libgcc statically while linking to SFML dynamically?

Why are the options BUILD_SHARED_LIBS and SFML_USE_STATIC_STD_LIBS mutually exclusive? If they were not exclusive, would I (theoretical) be able to achive the thing I explained before (static libgcc/stdc++ and dynamic SFML)?

[Nexus]

Why are the options BUILD_SHARED_LIBS and SFML_USE_STATIC_STD_LIBS mutually exclusive?

Because they lead to incompatible runtime libraries. See here for detailed information.

[Daddi]

So if I understand it correctly, the only simple way to distribute SFML programs is with a single executable with all dependencies linked statically?

At least for libgcc/stdc++ you would have to meet several requirements regarding their license (http://en.sfml-dev.org/forums/index.php?topic=12623.msg88259#msg88259) that require extra work?

Because of these legal requirements I wanted to link them statically without linking *everything* statically.

[eXpl0it3r]

If you use the audio module you'll have to provide sndfile and OpenAL as DLL due to LGPL license (unless your application is under GPL).

But yes the lowest number of DLLs can be achieved by linking SFML static with static runtime lib and then everything static for your application.

The libstdc++ issue applies only when distributing the DLLs, but it's really some stupid thing you'd only have to worry about for some really big application.

[Daddi]

But yes the lowest number of DLLs can be achieved by linking SFML static with static runtime lib and then everything static for your application.

I don't think you got my question right
Thats not what I wanted to achive, I knew that already about the static linking, its the process I currently use. I asked about the posibility to link the SFML library dynamically.

A: right now

Application.exe
libsndfile-1.dll
openal32.dll
 

B: wanted

Application.exe
libsndfile-1.dll
openal32.dll
sfml-audio-2.dll
sfml-network-2.dll
sfml-system-2.dll
sfml-window-2.dll
sfml-graphics-2.dll
 

C: only possible solution

Application.exe
libsndfile-1.dll
openal32.dll
sfml-audio-2.dll
sfml-network-2.dll
sfml-system-2.dll
sfml-window-2.dll
sfml-graphics-2.dll

libgcc_s_sjlj-1.dll
libstdc++-6.dll

+ legal attachments to gcc and stdc++
 

My question was about the possibility of solution B: distributing SFML DLLs without libgcc/stdc++ dlls and their legal attachments.

[eXpl0it3r]

Yeah that 's not possible...
Personally I really don't see an issue with distributing libstdc++. The only other possibility is to point the user to the compiler package with these DLLs, which is of course rathee stupid.

My personal guide line is: Either everthing static or everything dynamic.

[Daddi]

Thats all I wanted to know
Well then -> everything static it is

Btw @Nexus
http://www.bromeon.ch/games/index.html
These are yours, aren't they? If you start the games from another directory (different working directory), they run into a segmenation fault because the media files can't be read anymore (at least when I tried Airport)

[Nexus]

Btw @Nexus
http://www.bromeon.ch/games/index.html
These are yours, aren't they? If you start the games from another directory (different working directory), they run into a segmenation fault because the media files can't be read anymore (at least when I tried Airport)

Yes, they're mine

Thanks for the notice. I'm aware that not everything is perfectly waterproof, Airport will also crash if you simply remove the media. We once discussed the working directory issue, and it requires some effort to get right. For the moment, you have to run the game in the correct directory