How exactly are libopenal32 and libsndfile linked in static SFML (Windows)?

[Liag]

Hi, as I would prefer to release the library I'm currently working on as DLL-free as possible, I've been trying to compile OpenAL-Soft and libsndfile statically using MinGW/MSYS with gcc 4.7.0 on Windows 7 x64. This has proven to be rather tricky, but that will possibly be the subject of another (future) thread.

As my library is GPL3, the license would not be a problem.

What I'm concerned with right now, however, is how when statically building SFML with CMake on Windows it apparently (looking at Macros.cmake and generated build files) links to libopenal32.a and libsndfile.a just like the other external libraries, appending them to libsfml-audio-s.a. However, when using the audio module in a derivate project, it still requires the DLLs to run.

How is this accomplished? Are the static libraries just wrappers for the DLLs? And is there a way to use the provided libraries statically instead, without having to go through the trouble of building them myself?

Thanks for your help. I apologize if I assumed anything wrongly about the linking process.

Also, if anyone could direct me to a more suitable place for learning how to build either OpenAL-Soft or libsndfile with MinGW, or asking about these, I would be grateful.

[eXpl0it3r]

Afaik those *.a files which are shipped with SFML are only import libraries that give some information about the dlls but don't include the library itself, MSVC uses the *.lib type for such libraries.
If you want to link statically you'll have to work around this on your own. SFML doesn't provide another way, since it would conflict with its license (MIT).

[Liag]

I actually fail to see how linking LGPL libraries conflicts with the zlib license (which is what SFML actually uses), going by this chart published by the FSF:



Also: http://www.gnu.org/licenses/license-list.html#ZLib which indicates that even if they were licensed under GPL, SFML could link them statically.

Edit: The only thing which is required for statically linking an LGPL program is that you have to distribute the source code of the software, which isn't an issue in this case.

[eXpl0it3r]

The LGPL license states that you can use a library under that license in your closed source project only if it's linked dynamically.
Now SFML uses the zlib license, so you can use SFML without problems in a closed source project, but if you now would link the LGPL licensed library statically into SFML, you wouldn't be able to use SFML in a closed source project, since this would conflict the LGPL license, thus SFML can only claim to use 100% the zlib license if it uses the dynamically linked libraries of the LGPL licensed libraries.

In short:

• dynamic LGPL library: do whatever you want
• static LGPL library: release your source and then do whatever you want
• dynamic & static zlib library: do whatever you want
• dynamic LGPL library & dynamic/static zlib library: do whatever you want
• static LGPL library & dynamic/static zlib library: release your source and then do whatever you want

[Liag]

Ah, yes, I wasn't thinking in those terms. Obviously the issue wasn't with SFML itself.

And as far as I know, you don't have to distribute pure source code when statically linking to an LGPL library, you only need to release object code so that people can modify the library and link the object files to it. The license calls this "machine-readable" source code as opposed to human-readable. Still, making people do this could be rather inconvenient and would as you say make the static version of SFML not fully zlib in practice.

Would just be nice if it was easier to do for those who want it, I've noticed these libraries don't enjoy very much support for neither static building nor MinGW.