xiph
MINGW build problem with 1.3.4: any chance for a new release?
The MINGW build problem in 1.3.4 (fixed in master with commit https://github.com/xiph/flac/commit/14eb65de34e1df4da9a5e7333ddf3d9df93224c5), makes it impossible to upgrade Rust applications to version 1.3.4 of the FLAC library.
I'm using the libflac-sys Rust bindings in my little swyh-rs app. libflac-sys is currently stuck at FLAC release 1.3.3 because of the MINGW problem, see https://github.com/mgeier/libflac-sys/pull/20.
It would be nice to have a new release that fixes this showstopper for Rust users of the FLAC library.
The idea here is to release a little 'sooner than usual' (there have been only 5 releases in the last 10 years, the last being half a year ago), but quite a bit of work still needs to be done. There have been changes to the API (see #386) fuzz-testing needs time to cover these changes. Also, documentation needs to be updated.
So, I expect another release in a few months.
Would it be possible to back-port just the MinGW fixes and insert a quick 1.3.5 release before 1.4.0 with a new API?
Doing a release is a lot of work and several workarounds are available, so I'd rather not.
Similar question from me: would it be possible for libflac-sys to update to that specific commit instead of 1.3.4 or use one of the workarounds?
several workarounds are available
I'm not aware of workarounds, are they listed somewhere?
would it be possible for libflac-sys to update to that specific commit instead of 1.3.4
Yes, you are right, that probably makes more sense!
I've created a fork with a few selected commits on top of 1.3.4: https://github.com/mgeier/flac/commits/1.3.4+
However, this doesn't seem to work yet, see https://github.com/mgeier/libflac-sys/pull/24
Any ideas which commits are still missing?
BTW, 14eb65de34e1df4da9a5e7333ddf3d9df93224c5 is not relevant because it changes the autotools build system, but I'm using CMake.
One is listed in the commit message of 14eb65d: compiling with make LDFLAGS='-lssp'. LIBS='-lssp' or something similar probably also works, as long as the ssp lib is somehow added. For cmake I think this means `LIBS='-lssp' cmake.
It is also possible to turn off stack smash protection with cmake -DWITH_STACK_PROTECTOR=OFF