Linux/macOS support, idiomatic linkage about libfmod HOT 5 CLOSED

Hi!

Actually it works on MacOS. I haven't tested it on Linux, but I think it will work there too. All we need for support is to write clear instructions how to provide and configure linking of FMOD dynamic libraries on these platforms. At the same time make it flexible and more configurable, as you say.

I've been thinking for a long time that it's time to do this 😄

If you could make a PR with concrete suggestions how to do it, that will help a lot. You could simply provide a description of the ideas and pseudo-code. And I'll turn this into working solution.

Well, or I'll do it myself, just a later.

from libfmod.

Great! I'll take a shot at getting it going on macOS today. 😄

from libfmod.

Well, I stdied how it was done in crates like ash, sdl2, OpenXRs. Now there is no way to do it same because dynamic loading is not support by libmod and you still need to install FMOD libraries manually for dynamic linking.

But I added instructions how to install it on Linux and macOS in README. You can try them with new version 2.206.3

from libfmod.

Happy new year @lebedec!

Thanks so much for looking into this. I was able to get things working but, I'm a little bit confused about the linking stuff. A couple of things:

There is no simple way to control how Rust search for libraries

The usual way a crate that depends on some external dependency handles this is having the build.rs emit some linker flags, as described in this article.

dynamic loading is not support by libmod

I'm not sure I understand what this means. Are you talking about libfmod? Given that the libraries provided are dynamic libraries, rather than static libraries, I don't really understand what you mean by "dynamic loading is not support". Can you explain a little bit more?

from libfmod.

Happy new year!

Dynamic loading and dynamic linking are two different mechanisms for using shared libraries (*.dll, *.dylib, *.so). I don't think I can explain it better than what is written here. For now libfmod designed to only support dynamic linking. Dynamic loading is different and completely changes the crate code. I don't see it possible to implement right now.

Moreover, there is no real need for this. Dynamic loading is needed where dependencies are determined at runtime. For example, you are writing a graphics engine and want to change the graphics API on the fly between DirectX, Vulkan, and Metal for different host platform. This is why I think ash and Vulkan support dynamic loading. But for single dependencies, such flexibility is not needed. For example rust-sdl2 and SDL does not support dynamic loading. It’s very unlikely that you will change the window system in runtime, right? The same is true for sound engine FMOD.

About the ability to configure dev lib dependecies via build.rs. We can specify folder for search FMOD libraries for linking on compile stage. But for run time you still need to provide it manually. So I decide to use easiest instruction to configure FMOD dependency at once for compile and run time stages.

For example, for ash it works without manual configuration because VulkanSDK via it installation saves libraries to specific system folders (see ls /usr/local/lib | grep vulkan) and then works via dynamic loading. FMOD doesn't do it.

from libfmod.