Without this commit, building fails on MinGW because
-D_FORTIFY_SOURCE=2 needs runtime support which MinGW does not
provide. Building was possible with make LDFLAGS='-lssp'
This commit checks whether a symbol used by _D_FORTIFY_SOURCE=2 and
the stack smashing protector are available, and if so, enables these.
Resulting DLLs depend on the libssp DLL.
With autoconf 2.70, the behaviour of AC_C_VARARRAYS has changed,
causing a lot of warnings and as a result a cluttered make output.
Doing some research as to where this comes from, I found an strange
piece of code that seems to rely on a misunderstanding as to VLA's
in C++. As I found, the C++ standard does not have VLA's. The
configure.ac code and some code in libFLAC++ seems to think it does.
This now causes strange behaviour.
This commit removes the code relying on this behaviour and removing
all VLA related autoconf macro's from configure.ac
Autoconf 2.71 warns about obsolete macro's on running ./autogen.sh.
AC_PROG_CC_STDC is replaced by AC_PROG_CC as recommended by autoupdate
AC_HEADER_STDC has been removed. Autoupdate recommended the following:
> The preprocessor macro `STDC_HEADERS' is obsolete. Except in unusual
> embedded environments, you can safely include all ISO C90 headers
> unconditionally.
Starting with autoconf 2.70, obsolescence warnings are output by
default. To keep the script as compatible as possible, I build
autoconf 2.60 and ran the autoupdate that came with it on
configure.ac and all m4 files.
Now that many DACs support up to 768kHz, add support for these
sample rates to the encoder. Files produced with these sample rates
are already decodable by the reference decoder. Update documentation
and tests accordingly.
With this commit, it is possible to run the full test suite on
Windows machines when busybox-w32 is installed. This program is
available through chocolatey with 'choco install busybox'
CMake tests for availability of busybox and use if available. As
chocolatey is the preferred method of fetching software for
Github actions, this commit paves the way for running the full
test suite on Windows for CI
Without this patch, CMake places output binaries and libraries in
the respective source directories, like the autotools build system.
The Visual Studio build system places objects in the objs directory
Because CTest didn't run properly when building shared libs, this
commit changes the CMake behaviour on (NOT UNIX) to that similar
to Visual Studio. That way, DLLs and EXEs are placed in the same
directory and running CTest with the correct DLLs being loaded
is trivial.
Clang throws *a lot* of warnings on alignment requirement increase
where no alignment is required at all. This is a results of the
way intrinsics were implemented long ago. See
https://stackoverflow.com/questions/71279668/why-does-clang-complain-about-alignment-on-sse-intrinsic-unaligned-loads
This commit silences these warnings by first casting the pointer
to (const void*) or (void*) before casting the (const __m128i*),
(__m128i*), (const __m256i*) or (__m256i*)
Compiling with and without this patch returns exactly the same
binary for GCC 9.3 and clang 10.0
printf/fprintf prefer format specifiers rather than variable strings
(despite the const status). No functional change.
Fixes the following compiler reported warning:
warning: format not a string literal and no format arguments [-Wformat-security]
In stream_encoder_new, set_defaults_ was called before setting
encoder->protected_->state to uninitialized. However, this state
was being accessed by set_compression_level in set_defaults_. As
this is undefined behaviour, move the initialization of
encoder->protected_->state up to before calling set_default_
When verify mode is enabled, once decoder flags end of stream,
encode processing is considered complete.
CVE-2021-0561
Signed-off-by: Ralph Giles <giles@thaumas.net>
Previously the FLAC__AVX2_SUPPORTED macro is defined, but actually
AVX2 functions are not used when built with clang because flac only
uses them when FLAC__AVX_SUPPORTED macro is set.
Signed-off-by: NotTsunami
This is required on windows, but not on other platforms.
It needs to be the default `Debug` target, rather than
`Release` to match CMAKE_BUILD_TYPE, for the $TARGET_FILE
mapping to produce the correct path.
See https://gitlab.kitware.com/cmake/cmake/-/issues/20283
The main test harnesses are written in unix shell script, so
they don't work on windows. A stanza was added to the cmake
config to skip all tests there to get a green build.
This is misleading, since no testing was done at all on Windows.
Instead, construct a separate set of tests on non-unix platforms,
calling the two api test programs, which of necessity are
compiled executables. Also invoke the two front-end programs
with just the --help switch to verify they at least start.
Thanks to Marcus Asteborg for the suggestion.
Failures within multi-line commands aren't detected properly
in the windows runner environment. Therefore split each
line into a separate step for the cmake build.
Use the `working-directory` key to mark the build subdir without
having the prepend a `cd` command.
Make use of the available builders for Microsoft Windows build
converage.
Unfortunately this job reports finding no tests to run, despite
being identical to other builds. Worse, this is not reported as
an error.
Windows doesn't have a package manager like linux and macos, so
until we figure out how to build and cache the ogg dependency
for the windows job, just skip ogg support.
The test harnesses log details to files during the run,
which is helpful when debugging issues which are only
reported as a run failure in the console output.
When the build job fails, upload an artifact consisting
of a zipfile with all the log files from the build,
so users can investigate test failures in ci more
easily.
Define builds for gitlab's continuous integration runners so we
some feedback on versions of the code hosted there, particularly
https://gitlab.xiph.org/xiph/flac.
Build with GNU Autotools, with CMake+ninja, and verify
the Makefile.lite build.
This uses the same Debian-based docker.io/library/gcc:9 container
image we use for most of the codec projects. That container
doesn't specify an unprivileged user so that we can install
packages.
However, some of flac's file-creation tests must be run as an
unprivileged user who owns the source tree. We therefore
create a user account and use `su` to run the tests.
In the case of the autotools job, `make distcheck` unpacks
the packaged source, so this takes care of ownership.
In the case of the other jobs, we must `chown` the entire
checkout and complete the build as the unprivileged user.
Another way to address this would be to define a custom
container image with the prerequisites installed before
switching to an unprivileged user for the entire build.
The current approach was simpler to get working.
Details:
- During the installation of the package with CMake, it stops
(via fail) when doc files should be copied. It was caused by
changing current binary to current source CMake directory.
Details:
- When building with CMake, pkg-config files flac.pc and flac++.pc
are not updated with Version information. This causes a failure
when running a configure script in opus-tools
(https://github.com/xiph/opus-tools).
Note that OGG_PACKAGE is set to "ogg" exactly as in the configure.ac,
but it is only set when the building explicitly with libogg.
Don't attempt to attach failed metadata objects. This also avoids
clobbering the error flag if attaching the objects should succeed.
There may still be problems later, for example calling _delete()
on a possibly null metadata object pointer, but this it at least
and improvement in the compromise between error handling and
readability in C.
Signed-off-by: Ralph Giles <giles@thaumas.net>
Run the CI on PRs and once a month (to detect failures due to updated images or dependencies).
Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>
Signed-off-by: Ralph Giles <giles@thaumas.net>
