Exported symbol errors compiling under MSVC 2022 with CMake project
Brought to you by:
sobukus
Menu
▾
▴
#337 Exported symbol errors compiling under MSVC 2022 with CMake project
I don't know if there are others but after compiling both of the win32 output modules don't export their info ( mpg123_module_t mpg123_output_module_info) and also the out123_stringlists_free function isn't exported either. Everything compiles fine but when you go to link out123_stringlists_free is missing and the output modules won't load. I got it to work by throwing some __declspec(dllexport)'s in front of them though that isn't a proper fix of course :)
Oh, and this is with building shared DLLs of course.
So you're building all of mpg123 with MSVC? I'm not sure that has been tried before … in theory, things should juts work with cmake, but of course not in practice. The old MSVC projects were just about getting a libmpg123 DLL, not all the other stuff with it, like even libout123 and modules.
The static build is fine, right?
To conclude: Only
out123_stringlists_free()is missing from the library (no other symbols) and the modules need exporting of their entry point? This API function uses the sameMPG123_EXPORTmacro as the others. It should be expanded to dllexport whenBUILD_MPG123_DLLis defined (andLINK_MPG123_DLLwhen using the library). Hm, we miss that whole machinery in the cmake files, apparently. Seems like an obvious hole in the plan.Your libmpg123.dll is fine, though?
Any update on this? Right now there's a big
if(UNIX)in front of the build of the frontend binaries in ports/cmake …Were you just building libout123 and then tried to use it in a project of your own? The CMake build might need some love there.
Please give some details on this … we are discussing fixing up the CMake and MSVC build on bug #330 . Would be good to get this here sorted out, too, if it is a bug on our side.
I'll close this without further feedback. So far we don't do the output module stuff with MSVC, just the decoder library.