Yalir / sfeMovie

sfeMovie is a simple C++ library that lets you play movies in SFML based applications. It relies on FFmpeg to read medias and remains consistent with SFML's naming conventions.
http://sfemovie.yalir.org/
GNU Lesser General Public License v2.1
114 stars 37 forks source link

Fix issue with incompatibilities between libraries from different GCC on Windows #41

Closed Ceylo closed 10 years ago

Ceylo commented 11 years ago

Several GCC versions exist on Windows (namely the SJLJ and DW2 variants) which seem to produce issues if mixed.

This is an issue for CodeBlocks users, because the 1.0 sfeMovie build was built with the DW2 variant but CodeBlocks can also use SLJL, which makes the user program crash.

One could think of building sfeMovie with CodeBlocks's MinGW, but CB's MinGW doesn't include MSYS, which contains a bash interpreter on which sfeMovie relies (needed to launch the FFmpeg build).

Thus several paths to try:

Thought: if we keep the dependency to bash and to MSYS, we have to make sure that it's still the GCC from CB's MinGW that'll be used when building FFmpeg.

Ceylo commented 11 years ago

FFmpeg's configure script needs sh. Thus option 1 is not possible.

Ceylo commented 11 years ago

I could not reproduce the issue (test program built though CodeBlocks and running fine). There must be some configuration specific issues.

bluekirby0 commented 10 years ago

1) you can set up and use a custom toolchain with code::blocks if desired...but I'm guessing this isn't the desired solution. 2) http://tdm-gcc.tdragon.net/ provides DW2/SJLJ/SEH builds of gcc that are relatively easy to combine with an MSYS environment 3) you could simply modify msys.bat from a standalone MSYS distribution (one without a toolchain included) to include the code::blocks toolchain bin path in the windows PATH environmental variable before the environment is created. An example of how to do this (from a guide I wrote ages ago):

Find in your msys.bat

:startsh
if NOT EXIST %WD%sh.exe goto notfound

and add a line below that says:

set PATH=%PATH%;{Path to code::blocks toolchain}\bin

I would recommend picking ONE supported configuration for windows, as trying to support every possible combination of windows configurations is an exercise in insanity the like of which you rarely see working under other environments.

Ceylo commented 10 years ago

As you point out in the end, supporting all possible configuration is not realistic. I do not know what are the current usage shares between all configuration, but I'm wondering if supporting only VS2012, VS2013 and latest MinGW with MSYS would be enough.

bluekirby0 commented 10 years ago

Generally you have two main camps of windows developers: 1) The "pure" windows devs that work almost exclusively with MSVC and never really take portability into consideration 2) The people who work primarily on FOSS software where Windows is "just another platform to support" and generally stick with cygwin or msys environments for simplicity's sake (and because most projects are still using autotools for the build system

CMake is in a unique position to allow projects to support both configurations easily enough, and that is probably fine for the adventurous and those who really know what they are doing, but if you want to know which support will likely make more devs happy, it depends on which camp you really want to please. Oh and with C99 support in MSVC 2013, I would suggest supporting that exclusively on the MSVC side (the express edition is free, after all) since you are using ffmpeg.

On a side note, if you keep your linux builds clean, you will probably keep camp 2 happy without much effort.

Ceylo commented 10 years ago

On a side note, if you keep your linux builds clean, you will probably keep camp 2 happy without much effort.

Yep this is what I would like to keep :) As for MSVC, as it works fine with the current build system, even if it requires MinGW, I don't plan to change anything soon.

Ceylo commented 10 years ago

Using the official MinGW (DW2) works fine, and I don't wish to support other MinGW variants so I close this issue.