[flac-dev] 1.4.0 release candidate

[Martijn van Beurden]

Op do 1 sep. 2022 om 07:32 schreef Martijn van Beurden <mvanb1 at gmail.com>:

> I invite anyone interested to build from git, run the test suite and
> report back any problems. Comparisons of compression and speed between
> current git and 1.3.4 are also welcome.
>

Here are results I have

**github CI**
- x86_64 all combinations of Ubuntu/MacOS, GCC/Clang, autotools/CMake,
32-bit words/64-bit words
- x86_64 Windows CMake build static and shared
- x86_64 Ubuntu distcheck
are all fine

**travis CI**
- Aarch64 GCC+Autotools, GCC+CMake, GCC+CMake+64bitwords, GCC+CMake+noasm
- PPC64 GCC+Autotools, GCC+CMake, Clang+CMake, GCC+CMake+64bitwords,
GCC+CMake+noasm
are all fine

**oss-fuzz**
- Only timeouts reported, no aborts or problems with address sanitizer,
undefined sanitizer or memory sanitizer

**Own systems**
- x86_64 Ubuntu all combinations of GCC/Clang, Autotools/CMake,
shared/static, exhaustive tests with Autotools
- x86_64 Ubuntu GCC+Autotools, integer only and no asm optimizations
- Aarch64 Debian all combinations of GCC/Clang, Autotools/CMake,
shared/static, exhaustive tests with Autotools
- ARMv7 Debian GCC+Autotools and GCC+CMake, shared/static
- ARMv6 Debian GCC+Autotools, shared/static
are all fine

For x86_64 MinGW I tested all combinations of GCC/Clang, Autotools/CMake,
shared/static but had some problems here with the shared builds.
-DFLAC__NO_DLL is added to the Makefile to make sure test_libFLAC builds
with the static library only. Also, it seems the libtool wrapper executable
is not able to properly handle UTF-8 characters. When circumventing this by
placing the executable and library in the same directory (thus not needing
the wrapper to run the tests) the tests pass.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20220906/bfbfe96e/attachment.htm>