Linking dependencies

[Tank]

That's true, which reminds me of the first post:

[...]in my opinion telling/teaching them the right way is better than going for an easy approach with accepting that fatal bugs might happen.

[Laurent]

Hum..... .......... ......... .......... ..........

I'm really close to say "yes"

[binary1248]

Actually no conflict would (or should) occur. Intelligent (whatever that means) compilers/linkers have a well-defined order of going through their search paths and looking for the bits and pieces it needs. As Tank said, part of learning to develop applications consists of understanding things like this. If e.g. in Linux you want the cutting edge version of a library and the package manager only provides some 3-year-old version of it, you can always build it yourself. If done right it should not overwrite the existing version of the library but rather reside in a path that is checked earlier by the compiler/linker. This is the famous /usr/local directory many Linux distros come with and make use of. AFAIR /usr/local is checked before /usr and as such it should work as expected.

Even in Windows compilers often come with default versions of some libraries. Just because I specify that it should look in my own library directories first doesn't mean that if it finds multiple copies it will crash and die. The first occurrence takes precedence.

[Tank]

This is the famous /usr/local directory many Linux distros come with and make use of. AFAIR /usr/local is checked before /usr and as such it should work as expected.

Correct, however afaik the most used distribution, our beloved Ubuntu, changed that. /usr/local/ isn't included in $PATH anymore. Cheers!

[Cornstalks]

Such a change would indeed require the end-user to link to all the deps himself, but in my opinion telling/teaching them the right way is better than going for an easy approach with accepting that fatal bugs might happen.

I'd like this, personally. Is it possible for it to be a CMAKE option? To me that would be a win-win.

[Tank]

Have any decisions been made on this topic yet?

[Laurent]

No. My free time is so limited that I can hardly do anything that requires more than 10 minutes of my time.

[Tank]

Sounds very familiar to me.

I'll try to get some free minutes this evening to hack a patch.

[Laurent]

Thanks, but I wasn't talking about the time required to do the modification, but the time required to think about it and make a final decision

Before doing so I'd like to test it like a beginner (i.e. setup a project with static SFML libraries), to see whether the extra configuration steps are reasonable or not.

[Tank]

I know, but I'd like to see how it works out, too. And even if you'll decide not to do the modification, I will have to use a fork, therefore I need a patch anyway.

to see whether the extra configuration steps are reasonable or not.

Keep in mind the modifications aren't for being pro, but eliminating serious problems.

[eXpl0it3r]

I'd really like to see this change to happen soon...

Could you at least change the macro in a way that it doesn't assume the library path?
Because with mingw-w64 the libraries are not located in the root/lib but in root/some-strange-version-name/lib folder...
Also there should be x64 extlibs build for mingw.

[eXpl0it3r]

With the commit 5931236 where winmm has been added as dependency to sfml-system SFML is now in a state where it can't be built static with or without static runtime libraries on Windows with any MinGW version. I tested TDM 4.7.1, MinGW Builds POSIX SJLJ 8.4.1, Older Nuwen x86 4.7.1, new Nuwen x64 4.8.1, Old official MinGW version, official MinGW 4.8.1 version and even MinGW 4.9-testing, etc.
It was also tested on Windows 7 as well as 8.1 and others.

So why am I posting this here? Because this topic here is exactly the issue, why SFML is crashing in the linker. The macro that "magically" includes every dependency into SFML up on static linking leads to the case the both sfml-window and sfml-system have their own version of winmm and when linking both libraries ld crashes "somewhere".

Now that we have an even more concrete reason why including everything into SFML is a bad idea, can we finally get a change and throw that horrible macro out? Please?

If you want another topic for the issue specific and/or a ticket let me know!

Phew "wasted" 3 days to track this issue down...

[FRex]

SFML is now in a state where it can't be built static with or without static runtime libraries on Windows with any MinGW version

As in: can't be built static by MinGW at all?

Phew "wasted" 3 days to track this issue down...

I'm giving you a considerable amount of brag-rights-currency for tracking that down.

[eXpl0it3r]

As in: can't be built static by MinGW at all?

You can build the lib, but once you try to link the window and the system module and invoke winmm calls in each library ld will crash.
The following example is enough:

#include <SFML/Window.hpp>
#include <SFML/System.hpp>

int main()
{
    sf::Mouse::getPosition();
    sf::Clock clock;
}

[eXpl0it3r]

There's an easy fix by making the window module not depend on winmm and since it depends on the system module everything should be fine.

I bet this "solution" will chosen instead of solving the real issue here.