Issues linking when linking against static version of OpenAL #412
Labels
Milestone
Comments
|
Hi! Not sure what's happening here. If you check what symbols the static OpenAL exports, are those listed in the exact same form or mangled differently? Another cause might be that the library actually has them, but the header marks them as I never built OpenAL Soft myself, so that's about all I can suggest, sorry :) |
|
The changes done in 25f7d79 should make static OpenAL work better especially when it comes to 3rd party dependencies, but I'm not sure if it really fixes this issue as well, as that seems to be rather some issue with symbol export than with improperly handled transitive dependencies. @hsdk123 could you confirm/deny, please? :) |
|
Good to see we're pushing through this! I'm still getting the undefined symbols with the static build: |
|
Too bad I don't understand how the link libraries are passed to This is with the updated FindOpenAL? Can you explicitly link |
|
Hmm, interesting... Would you be able to make sense of this? |
|
(this is when I explicitly add OpenAL::OpenAL as a link dependency) |
|
Oh, vcpkg? Wait, I thought you have a hand-built static version. With vcpkg I'm aware of a linker error shown at microsoft/vcpkg#10158 (comment), but that's an error one step after the one you have.
The original FindOpenAL (which is based on the vanilla one from CMake) didn't create any find_package(OpenAL REQUIRED)
target_link_libraries(LightApp ... OpenAL::OpenAL) |
Yup, I'm using the hand-built static version, and with the updated FindOpenAL. Not sure why vcpkg is coming up. I can confirm that this finishes the cmake generate portion without problem, although I needed to copy the FindOpenAL.cmake inside magnum/modules into my top level modules/ However, even after doing this, and rebuilding, I still get the same unresolved symbol errors. I get the feeling the error's somewhere else |
|
Hum, then it's probably what i thought at first -- that the static build is weird in some way. And looking at what vcpkg does for static build, yep, that's definitely it: https://github.com/microsoft/vcpkg/blob/master/ports/openal-soft/dont-export-symbols-in-static-build.patch |
|
Might potentially be faster to just ask the maintainer of openal soft, the person seemed kindly fast with replies. |
|
The vcpkg patch seems to be what needs to be integrated upstream, yep. Can you verify locally that it helps and then ask the maintainer about it? (I'm not really on Windows, so I can't help much in this regard.) |
|
The openal-soft maintainer got back super quick, it seems adding fixes the build (and I could get rid of the extra target_link_dependency) - it looks as if magnum would need to add the compile option in the event we use a static build of openal. |
|
I have to admit that's quite an unusual way to do static builds. What's often done (and what magnum does also) is that the library installs a configure header that has this definition embedded (or it adds that to the main headers during build/install). Looking at its CMakeLists, this definition is added, so if we're using the imported target (which the fancy new For a non-imported case (where I'm just finding the libraries on the disk, without OpenALConfig), the problem is that I can't reliably detect if the build is static. On Windows you always link to |
|
I don't seem to see the define inside here, but here are the 2 files: OpenALConfig-relwithdebinfo.cmake |
|
Just tried building latest Git master locally (on Linux), and this is what I get in ...
set_target_properties(OpenAL::OpenAL PROPERTIES
INTERFACE_COMPILE_DEFINITIONS "AL_LIBTYPE_STATIC"
INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include;${_IMPORT_PREFIX}/include;${_IMPORT_PREFIX}/include/AL"
INTERFACE_LINK_LIBRARIES "\$<LINK_ONLY:-pthread>;\$<LINK_ONLY:dl>;\$<LINK_ONLY:atomic>;\$<LINK_ONLY:m>"
)
...The Can you confirm that, if you build from latest Git master, the linking issue goes away even without explicitly defining |
|
I get the following logs, but I can confirm that the build (with master) completes without the definition! |
|
What's interesting is that if I explicitly readd then the LNK4217 warnings go away |
|
What's more interesting is that if I do the explicit addition This also goes away. |
|
Is Magnum recompiled against the openal git master also? To me it looks like MagnumAudio.lib didn't receive the With the updated config file in OpenAL Git master and latest |
|
Just for reference, I've been trying repeatedly over the last couple of weeks to get things to compile on msvc without the warnings, but it doesn't seem to happen without manually defining I'm unsure as to why this is happening, but I understand that there might not be anything else possible through magnum automatically. I'll reopen this if I can maybe find a workaround, as of now, I can agree this might not be high priority. |
|
OK, let's keep this open until it's fully resolved :) ... or at least until next stable OpenAL soft is released, with the define correctly exposed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi, I'm attempting to use a static version of OpenAL built through the repo here: https://github.com/kcat/openal-soft
Using a dynamic library build of OpenAL seems to link fine, whereas using the static library seems to cause linker errors. CMake configuration went fine and thus I'm somewhat puzzled as to what's happening.
Log:
The text was updated successfully, but these errors were encountered: