As it turns out that the PPC-specific code provides no benefit with
modern, autovectorizing compilers, and given that there is a lot of
cruft surrounding the PPC-specific parts, remove all of it.
See also https://lists.xiph.org/pipermail/flac-dev/2022-December/006620.html
Remove default addition of msse2 on x86. After profiling it was
found this helps little on modern systems. See
https://github.com/xiph/flac/issues/486
The mention of Asm optimizations at the end of configuration was
wrong in many ways: it was 'yes' on platforms for which there are
no optimizations, and wasn't set to 'no' in case intrinsics headers
aren't available.
* Do not make empty man pages, use either pandoc or prebuild
A check is added to configure whether flac.1 and metaflac.1
are already build when pandoc is not available. This is the
case in for example dist packages
* Fix typo in new automake conditional
Tool documentation has moved to man directory, other dev docs to
README.md and CONTRIBUTING.md. User documentation is already on
the website and doesn't really belong in the source code. Also, fix CMake
so that it uses Doxyfile.in instead of using defaults.
Currently, the man pages are converted from a docbook document, but
the conversion doesn't seem very reliable. Also, the man page is
more-or-less duplicated by the html documentation.
This commit moves all tool documentation to a markdown document which
is readable by itself and can be converted by pandoc to a man page
and can be used by Jekyll to populate the website.
Commit 4fbb6d4f2e reverted commit
44036c9a9b and so broke again the build on
uclibc
So put back the sys/auxv.h check as well as a getauxval check in a way
that doesn't break iOS
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
In some circles (Hydrogenaud.io for example) people share binaries
compiled from git, i.e. inbetween official releases. Files created
with these binaries cannot be discerned from others. To improve
troubleshooting, compiles from a git repository are marked with
the commit hash and date when configured with autotools or CMake
This changes the names of the two fuzzers so they align with
current oss-fuzz usage (to provide continuity in test data and
corpora) and adds a dictionary to the decoder fuzzer. It also
removes some unnecessary configuration, as it clashed with oss-fuzz
defaults
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.
This commit contains the following changes:
- Drops -fstack-protector in favor of -fstack-protector-strong.
Consequently, the ssp-buffer-size parameter has been removed as
-fstack-protector-strong ignores array size.
- Add new global opt-out for stack smash protection. This is enabled
by default for both autotools and CMake builds. Users can opt out
of stack smash protection by passing -DWITH_STACK_PROTECTOR=OFF to
CMake or --disable-stack-smash-protection when running ./configure.
- Renames HAVE_SSP_FLAG to HAVE_STACK_PROTECTOR_FLAG in
CMakeLists.txt to be more readable.
These fuzzing targets were originally from:
https://github.com/guidovranken/flac-fuzzers.git
but having them in a separate repo was a huge pain in the neck when
working on fixing any problems found.
The flac configury marked clang as 'not being gcc' and excluded
a lot of compiler switches, most importantly the visibility flags,
from being used with it. This was done possibly after a problem
reported at: https://github.com/erikd/libsndfile/issues/49 .
This patch does the following:
- m4/gcc_version.m4 (XIPH_GCC_VERSION): set GCC_MAJOR_VERSION and
GCC_MINOR_VERSION to 0 for non-gcc. Previously, they were left
unset.
- configure: the gcc version checks are, naturally, against non-
zero values, so, allow many compiler switches to be used with
clang without affecting real-gcc cases.
- configure: When setting CFLAGS="-O3 -funroll-loops", also set
CXXFLAGS="-O3". Prevents g++ warnings with _FORTIFY_SOURCE, i.e.:
'_FORTIFY_SOURCE requires compiling with optimization (-O)'
Tested compilation using gcc-7.3.1 and clang-5.0.2 on x86_64-linux,
and gcc-4.4.7 and clang-3.4.2 on an i686-linux. Also tested cross-
compiling for Mac OS X using clang-5.0.2.
the issue is, flac and metaflac exes rely on flac_internal_???_utf8()
procedures from windows_unicode_filenames.c and there is no easy way
to exclude them from exports without breaking things. So export them
explicitly (they are exported anyway w/o this patch), but add a FIXME
note about the kludge in windows_unicode_filenames.c.
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
---
Note: One of the buildroot autobuilder provided powerpc toolchains
seem to not provide the sys/auxv.h header file, resulting in a
compile failure (see [1] for details).
[1] http://lists.busybox.net/pipermail/buildroot/2019-September/259732.html
Check if the compiler supports __attribute__((target("cpu=power8")))
and __attribute__((target("cpu=power9")))
Signed-off-by: Amitay Isaacs <amitay@ozlabs.org>
FLAC__CPU_PPC wasn't catching powerpcle or powerpc64le. Fix that and
add a new define for FLAC__CPU_PPC64.
Signed-off-by: Anton Blanchard <anton@ozlabs.org>
