As contribs keep being updated with newer versions of the language, we need to
support a more modern version of C++ going forward.
Setting -std=c++17 should not break existing contribs that are built with C++11 or C++14.
In fact we already support the mix of versions between 11 and 14 without problem.
Modern C++ compilers are designed to take care of this [1].
When switching to a new C++ version there might however be some slight differences on how the
code is interpreted. These differences [2] might trigger some build errors for removed parts.
[1] https://stackoverflow.com/questions/46746878/is-it-safe-to-link-c17-c14-and-c11-objects
[2] https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0636r3.html
C compilers can have GNU extensions to support typeof in C code, but
some C++ compilers like clang are removing the builtin since decltype
can be used in C++ without the constraints from typeof. Decltype is not
100% equivalent for this reason: references will be kept in the returned
type.
The check in m4/typeof.m4 comes from graydon/monotone and dovecot/core
and was slightly modified to namespace the define for C++ code.
The m4 file is a dependency of lib-prefix, leading to error at
bootstrap because it was missing after update from commit
32b3f47bf0.
configure.ac:618: warning: gl_HOST_CPU_C_ABI_32BIT is m4_require'd but not m4_defun'd
m4/lib-prefix.m4:155: AC_LIB_PREPARE_MULTILIB is expanded from...
m4/lib-link.m4:181: AC_LIB_LINKFLAGS_BODY is expanded from...
m4/iconv.m4:10: AM_ICONV_LINKFLAGS_BODY is expanded from...
m4/gettext.m4:55: AM_GNU_GETTEXT is expanded from...
configure.ac:618: the top level
configure.ac:618: warning: gl_HOST_CPU_C_ABI_32BIT is m4_require'd but not m4_defun'd
m4/lib-prefix.m4:155: AC_LIB_PREPARE_MULTILIB is expanded from...
m4/lib-link.m4:181: AC_LIB_LINKFLAGS_BODY is expanded from...
m4/iconv.m4:10: AM_ICONV_LINKFLAGS_BODY is expanded from...
m4/gettext.m4:55: AM_GNU_GETTEXT is expanded from...
configure.ac:618: the top level
autoreconf: configure.ac: tracing
configure.ac:618: warning: gl_HOST_CPU_C_ABI_32BIT is m4_require'd but not m4_defun'd
m4/lib-prefix.m4:155: AC_LIB_PREPARE_MULTILIB is expanded from...
m4/lib-link.m4:181: AC_LIB_LINKFLAGS_BODY is expanded from...
m4/iconv.m4:10: AM_ICONV_LINKFLAGS_BODY is expanded from...
m4/gettext.m4:55: AM_GNU_GETTEXT is expanded from...
configure.ac:618: the top level
The macro was checking for $with_foo to be set but only $enabled_foo was
set correctly by the PKG_WITH_MODULES macro. In addition, this patch
adds an intermediate macro for the name to be readable.
Part of the test is leaking memory, which can trip the leak sanitizer.
(This should be fixed in gettext. In the mean time, it will need to be
applied manually at every gettext update.)
Both gcc and clang generate warnings for unsupported -f$FLAG by
default, meaning that the previous implementation would consider
unsupported flags as supported (as a warning is not an error that
fails compilation).
The addition of -Werror treats warnings as errors, and will prevent
false-positives in terms of -f$FLAG support.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
mingw (both 32 and 64) provides a number of functions that have no C
linkage, but are only available as static inline. Define a macro that can
check for the function declaration but acts like AC_REPLACE_FUNC.
Use the new macro for asprintf/vasprintf (previously implemented in
configure.ac directly).
Signed-off-by: Diego Elio Pettenò <flameeyes@flameeyes.eu>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Shorten build time.
On x86_64 linux build:
LIBTOOL make -j2 60,82s user 13,98s system 112% cpu 1:06,59 total
make -j2 56,83s user 12,72s system 110% cpu 1:03,20 total
DOLT make -j2 44,32s user 11,02s system 108% cpu 51,215 total
make -j2 42,15s user 11,04s system 106% cpu 50,155 total
Signed-off-by: Rafaël Carré <funman@videolan.org>
Steve Lhomme