Define STB_IMAGE_STATIC and STB_IMAGE_WRITE_STATIC

[FRex]

We should define those two macros in ImageLoader.cpp so that a statically linked SFML doesn't collide and cause tons of linking errors when the user's program also includes their own STB without defining those macros (they make all stb functions static).

Yes, I know I'm inventing random niche problems daily.

[eXpl0it3r]

Sure, why not.

[FRex]

I'm not sure what the was for, are you agreeing or not? Reason as to why not would be if more files included those two headers but they don't (unless I missed something) so it's not an issue at all.

And to make it clear, I mean #define in the code of ImageLoader.cpp before including those two headers, not in any build/project settings.

Oh, and wouldn't it produce "unused static function" errors in some cases? It still should be done though.

On the other hand this might make this part of code marginally faster and the built SFML a bit smaller if unused functions get stripped out, not that it matters for these parts of code.

[eXpl0it3r]

Oh, I didn't want to sound ambiguous.

If there are no obvious down sides, then I don't see a reason, not to go ahead with it.

[FRex]

Those warning that might appear are the only downside. Let's see what Laurent says.

[Laurent]

Laurent says he doesn't really care, but Laurent could also say "don't fix it if it isn't broken"

[FRex]

It is broken. Linking SMFL statically + using STB in your own code without those macros on your side = linking errors. A lot of "LNK2005   _stbi_load_from_memory already defined in main.obj" will happen (for various functions). SFML's internal details shouldn't force a user to do that. Especially if we can fix it in two lines that'll also make the compiled code smaller and/or faster. It's like a smaller scale version of when static SFML linked its deps statically.

Oh, you also get one "LNK1169 one or more multiply defined symbols found".

[Laurent]

It is broken. Linking SMFL statically + using STB in your own code without those macros on your side = linking errors.

Ok, so you actually tried it, it was not a guess. So go ahead and fix it, sure

[FRex]

Jesus. Yes.



And I didn't need to try to know it'd happen (but I tried it yesterday just to be sure). I just thought of this problem again when I thought that right now the only way to save png to memory is to use stb_image_write (or something else) yourself.

Actually it's kinda ironic that it's SFML that misses this save-to-memory functionality, thus forcing you to use stb_image_write yourself but then it turns out SFML in static linking prevents you from doing that...

[FRex]

Defining STB_IMAGE_WRITE_STATIC causes dynamic SFML Graphics to fail to build with "LNK2019   unresolved external symbol _sprintf referenced in function __bdf_parse_properties   sfml-graphics   D:\sources\SFML\src\SFML\Graphics\freetype.lib(bdf.obj)".

Static SFML Graphics builds but then fails with same error unless  you use sprintf in your code.

So bdf.obj needs that, and unless some user code (or our stbi_image_write) pulls it in by calling it somewhere it fails to link.

It fails with this define because only function in stbi_image_write that calls sprintf is stbi_write_hdr_core which never gets called by SFML or any functions it calls so it gets stripped from the .obj by the compiler.

This is correct and adding legacy_stdio_definitions.lib to linker in either cases removes the _sprintf missing error: https://stackoverflow.com/questions/32418766/c-unresolved-external-symbol-sprintf-and-sscanf-in-visual-studio-2015

My brain right now...

[eXpl0it3r]

I'd rather pick the other option recommended in the SO answer to rebuild freetype with the "correct" VS 2015 version. Only question is then whether there could be some compatibility issues, but if it's just for an older version of VS 2015 or similar, then that's fine.

Soon we can drop the non MSVC universal libs, once VS 2019 comes out.

[FRex]

I have no idea. This is pretty WTF. Like I know there is a warning/error when using these 'unsafe' functions but this is a whole new level of WTF. And the fact this one unused function in image write was saving us...

Soon we can drop the non MSVC universal libs, once VS 2019 comes out.

Oh, why? And what's the difference between stuff in libs-msvc-universal and libs-msvc?

[eXpl0it3r]

Because we're only ever providing builds for three different VS versions. With VS 2019 getting released soon, that will be VS 2015, 2017 and 2019 which all use the Universal CRT (see here). I guess it's something to discuss with the rest and kind of off-topic here.

[FRex]

Builds of what? Extlibs? Because the extlibs are the problem here. CMake files we give are supposed to support 3 last version of VS?

I'm still mind blown this happens to work right now (flawlessly since VS 2015!!!) because sprintf is used once in a function we never use...

And the fact this prevents us from just defining STB_IMAGE_WRITE_STATIC...

We can define STB_IMAGE_STATIC no problem though!