(Resolved) Issues compiling statically with the audio library

[Sheepyhead]

Hey there folks, new user of SFML here, and I love the API so far! I'm having some issues linking with the audio module, as the flac.lib provided in extlibs seems to be somewhat outdated. I'm running into the issue that is documented on stackexchange where some standard definitions seem to have changed slightly in MSVC, see https://stackoverflow.com/questions/30412951/unresolved-external-symbol-imp-fprintf-and-imp-iob-func-sdl2

So when I attempt to compile, linking the audio library, along with its dependencies I get this error:
https://i.imgur.com/UvMKgN8.png

My compile command is the following:

cl /FC /EHsc /MDd /D_ITERATOR_DEBUG_LEVEL=2 /I ..\submodules\SFML\include ..\src\main.cpp /DSFML_STATIC /link /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.17763.0\um\x64" OpenGL32.lib WinMM.lib Gdi32.lib user32.lib advapi32.lib /LIBPATH:"../submodules/SFML/extlibs/libs-msvc/x64" OpenAL32.lib flac.lib vorbisfile.lib ogg.lib vorbisenc.lib vorbis.lib /LIBPATH:"../submodules/build/SFML/lib/Debug" sfml-main-d.lib sfml-system-s-d.lib sfml-window-s-d.lib sfml-graphics-s-d.lib sfml-audio-s-d.lib

Has anyone encountered this issue before? How do I get past this?

[FRex]

Then try add 'legacy_stdio_definitions.lib' to the libs you're linking (it's part of MSVC)? It says so in your stack overflow link and with another prebuilt library (freetype) this problem also exists but is hidden/doesn't apply due to a funny quirk.

[Sheepyhead]

Then try add 'legacy_stdio_definitions.lib' to the libs you're linking (it's part of MSVC)? It says so in your stack overflow link and with another prebuilt library (freetype) this problem also exists but is hidden/doesn't apply due to a funny quirk.

It worked! At least for the print issues, but now I'm left with the __iob_func issue, to which the solution seems non-trivial and the code provided in the link is exclusive to x86 and highly experimental. Can it really be that this project is not suitable for modern use? Seems strange to me that it would preclude use by a contemporary compiler like that..

[FRex]

The issue is due to dependencies being built using an older MSVC. For __iob_func there is a work around listed in accepted answer on SO that you linked. I'm not sure what you mean by x86 specific or experimental.

[Sheepyhead]

I'm not sure what that __iob_func is. The issue itself is due to dependencies being built using an older MSVC.

Yeah I figure my best bet is to set up my own compilation of the flac library. Pain in the neck but hey what can you do. Might be worth it to request that the libraries in the repo are updated I guess

[FRex]

I edited my last answer, there is workaround code in your SO link, I'm not sure what you mean by it being experimental and x86 specific.

[Sheepyhead]

I edited my last answer, there is workaround code in your SO link, I'm not sure what you mean by it being experimental and x86 specific.

The closest I've seen to a proper workaround in the thread is Mark H's reply, which is highly experimental and also x86 specific.

[FRex]

I looked at just accepted answer before, I read that one now and it's all correct, that array and FILE changing sizes is really bad. The only way to fix it is to recompile with newer VC++ after all.

[Sheepyhead]

I looked at just accepted answer before, I read that one now and it's all correct, that array and FILE changing sizes is really bad. The only way to fix it is to recompile with newer VC++ after all.

Yeah seems like it. They should update the library (assuming doing that wouldn't break anything) in the repo

[FRex]

Did you ever try the ones in SFML/extlibs/libs-msvc-universal?

[Sheepyhead]

Did you ever try the ones in SFML/extlibs/libs-msvc-universal?

Dur I can't believe I didn't think of that, those work as expected (even without the legacy definitions lib). Thanks for the help!