SFML x64 cause QT to stall... window.lib compatibility issue

[golgoth]

Greeting,

There is one major issue I really don’t know how to solve, and chances are no one will... but I'll give it a shot anyway.

When linking sfml-window.x x64/MT and QT x64/MT. For some reason, QT API gets stall apparently in its main loop exec(), which doesn’t happen with the x86 /MT version.

Another example is that I'm linking my project library (including sfml-window-s.lib) to a Softimage 2010 C++ plug-in. When loading the plug-in, Softimage gets stall before any plug-in callbacks are being executed. I never had that problem before with SDL and I'm using a few other libs like FMOD and Nvidia Physx.

I understand those are quite specific problematic and hard to reproduce. I might be wrong, but my guess is there is something unusual with the sfml-window-s.lib that is causing conflicts and might need investigation. One thing is for sure at the moment, I'm staring at the abyss and I'm getting sucked in.

Any idea?

[Laurent]

Did you recompile SFML?

[golgoth]

Yes, using the static settings altered to /MT instead of /MD.

[Laurent]

The external libraries used by SFML were probably compiled using /MD, so unless you recompile the whole chain, I'm afraid you won't be able to make it work with /MT. Is there a good reason why you want to do that?

[golgoth]

Oh I see,

using /MT did link libraries more easily compare to /MD, is there any reason why not to use /MT?

[Laurent]

/MT is not a good option when multiple libraries are involved, as they'll all use their own embedded copy of the standard library. This can cause many potential issues.
With /MD, they all use a single shared standard library.

/MT is not a solution, the "right" thing to do when distributing an application compiled with Visual C++ is to make sure that the clients will have the VC++ redistributable files installed.

[golgoth]

I'll definitely try this, thanks for your inputs Laurent, really appreciated.

Cheers

[golgoth]

After recompiling every libraries with /MD I’m getting the exact same results… Oh well, at least I’m having all the latest libs now  

Quick question: when A.lib is compiled using lib.B… is it possible to link lib.A without lib.b?

[dunce]

Quick question: when A.lib is compiled using lib.B… is it possible to link lib.A without lib.b?

Yes. This is just what you can see in sfml-graphics-s.lib. It is linked to freetype.lib. Thus you need not link to freetype.lib in your own project that uses sfml-graphics-s.lib. [If I understood your question right.]

[golgoth]

Humm… can I link SFML to my project with Freetype enabled and turn it off without recompiling SFML?

[Laurent]

Why do you want to "turn it off"??

[golgoth]

Another example is that I'm linking my project library (including sfml-window-s.lib) to a Softimage 2010 C++ plug-in. When loading the plug-in, Softimage gets stall before any plug-in callbacks are being executed. I never had that problem before with SDL and I'm using a few other libs like FMOD and Nvidia Physx.

I m currently working on building an DLL + LIB... but I m having trouble with:

template __declspec(dllexport) std::vector<int>;

seems to be a well known issue but I cant get it to work yet... what a nitghmare that is!