Messages

1

General / Re: Switch from 1.6 to 2.0

« on: July 05, 2012, 08:24:58 am »

I'm assuming you use the 2.0 RC. If so, did you get the DW2 or SJLJ download? Default Code::Blocks MinGW g++ uses SJLJ, and it is marked as that on the downloads page, so that is more likely.

The VS error is because you're trying to solve the exception, which Windows tries to start its native debugger for. Quoting MSDN:

Just-In-Time debugging is a feature that launches the Visual Studio debugger automatically when a program, running outside Visual Studio, encounters a fatal error.

Try checking the call stack instead.

2

Audio / Re: How exactly are libopenal32 and libsndfile linked in static SFML (Windows)?

« on: July 03, 2012, 10:41:47 pm »

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.

3

Audio / Re: How exactly are libopenal32 and libsndfile linked in static SFML (Windows)?

« on: July 03, 2012, 07:39:50 pm »

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.

4

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

« on: July 03, 2012, 04:01:02 pm »

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.

5

General / Re: Creating Libraries with SFML

« on: July 03, 2012, 02:59:27 pm »

You simply link to SFML as with a normal application, choosing to build a library instead.

If you are building the library dynamically, you simply need both the SFML libraries (along with the required external libraries) and your library when running a program using your library. The program only needs to link to your library in this case, since it automatically loads the SFML ones. SFML then loads the external libraries, etc.

If you are building it statically, the library doesn't actually do any direct linking to SFML, and any program using your library has to link to SFML as well. In this case, when using Windows only the external libraries OpenAL32 and libsndfile need to be present (using linker options -static-libgcc and -static-libstdc++).

On Windows, the static SFML libraries use a special way of compiling the dependencies so that you don't have to link them in subsequent projects, but this requires rather advanced usage of CMake and may be rather difficult. This is defined in SFML/cmake/Macros.cmake.

This should be possible on Linux as well, but it's not officially supported, since static linking is rather uncommon on the platform. It's pretty useful for a more specific library, though.

As far as I know, for OS X SFML only officially supports XCode/LLVM which typically uses dynamic linking. Using gcc, it should be the same as on Linux.