This enables the following additional warnings:
-Wold-style-definition
-Warray-bounds=2 instead of the default 1
-Wformat=2, but only for GCC 4.8+ as Wno-format-nonliteral is not
respected for older versions
-Wunused-const-variable, which enables level 2 instead of the default 1
-Warray-bounds also in debug mode through -ftree-vrp
-Wnull-dereference also in debug mode through
-fdelete-null-pointer-checks
Closes https://github.com/curl/curl/pull/2747
This enables level 4 instead of the default level 3, which of the
currently used comments only allows /* FALLTHROUGH */ to silence the
warning.
Closes https://github.com/curl/curl/pull/2747
This warning used to be enabled only for clang as it's a bit stricter
on GCC. Silence the remaining occurrences and enable it on GCC too.
Closes https://github.com/curl/curl/pull/2747
First check if there's c-ares information given as pkg-config info and use
that as first preference.
Reported-by: pszemus on github
Fixes#2203Closes#2658
They are removed from the compiler flags.
This ensures that make dependency tracking will force a rebuild whenever
configure --enable-debug or --enable-curldebug changes.
Closes#2548
... only set it when we actually have to run tests to reduce its impact
on for example build commands etc.
Fixes#2490Closes#2492
Reported-by: Dmitry Mikhirev
- Add OpenSSL 1.1.1 to the header/library version lists.
- Detect OpenSSL 1.1.1 library using its function ERR_clear_last_mark,
which was added in that version.
Prior to this change an erroneous header/library mismatch was caused by
lack of OpenSSL 1.1.1 detection. I tested using openssl-1.1.1-pre1.
The logic tries to figure out what the path separator in the $PATH
variable is, but if there's only one directory in the $PATH it
fails. This change make configure *guess* on colon instead of erroring
out, simply because that is probably the more common character.
PATH_SEPARATOR can always be set by the user to override the guessing.
(tricky bug to reproduce, as in my case for example the configure script
requires binaries in more than one directory so passing in a PATH with a
single dir fails.)
Reported-by: Earnestly on github
Fixes#2202Closes#2265
This updates the script to aad5ad5fedb306b39f901a899b7bd305b66c418d
from August 01, 2017. Notably, this removes the lconv version whitelist.
Closes https://github.com/curl/curl/pull/1716
When building with Cygwin or MinGW, libtool uses a wrapper executable
instead of a wrapper script [1], which is written in C and throws
missing-variable-declarations warnings. Don't enable these warnings on
Cygwin and MinGW in order to avoid warnings for every executable built,
which spams the test suite output when using Cygwin's clang.
[1] https://www.gnu.org/software/libtool/manual/html_node/Wrapper-executables.html
Closes https://github.com/curl/curl/pull/1665
Since 5598b0bd63, clang -v is used to
detect the clang version. The version number was expected to come after
the word "version". For Apple clang, this doesn't work as it has its
own versioning scheme.
The version number is now first searched after the string
"based on LLVM". This works for Apple clang before version 7, and also
for e.g. Ubuntu's clang up to version 3.7. If it's not found and the
version string contains "Apple LLVM version", clang version 3.7 is
assumed, which is the version that comes with Xcode 7. Otherwise, the
version number is still expected after the word "version", which works
for very old Apple clang versions.
Ref: https://trac.macports.org/wiki/XcodeVersionInfo
Fixes https://github.com/curl/curl/issues/1606
Closes https://github.com/curl/curl/pull/1607
Previously, that warning was only implicitly active in C90 mode.
Enable it unconditionally as already done for GCC.
Closes https://github.com/curl/curl/pull/1578
- Change prepends to appends because user's LDFLAGS and CPPFLAGS should
always come first so they're searched before ours.
Bug: https://github.com/curl/curl/issues/1420
Reported-by: Helmut K. C. Tessarek
We're mostly saying just "curl" in lower case these days so here's a big
cleanup to adapt to this reality. A few instances are left as the
project could still formally be considered called cURL.
Some builds of GCC produce output on both stdout and stderr when --help
--verbose is used. The 2>&1 redirection caused them to be arbitrarily
interleaved with each other because of stream buffering. Consequently,
grep failed to match the fvisibility= string in the mixed output, even
though the string was present in GCC's standard output.
This led to silently disabling symbol hiding in some builds of curl.
These configure vars are modified in a curl-specific way but never
evaluated or loaded from cache, even though they are designated as
_cv_. We could either implement proper AC_CACHE_CHECKs for them, or
remove them completely.
Fixes#603 as ac_cv_func_gethostbyname is no longer clobbered, and
AC_CHECK_FUNC(gethostbyname...) will no longer spuriously succeed after
the first configure run with caching.
`ac_cv_func_strcasecmp` is curious, see #770.
`eval "ac_cv_func_$func=yes"` can still cause problems as it works in
tandem with AC_CHECK_FUNCS and then potentially modifies its result. It
would be best to rewrite this test to use a new CURL_CHECK_FUNCS macro,
which works the same as AC_CHECK_FUNCS but relies on caching the values
of curl_cv_func_* variables, without modifiying ac_cv_func_*.
These configure vars are modified in a curl-specific way and modified by
the configure process, but are never loaded from cache, even though they
are designated as _cv_. We should implement proper AC_CACHE_CHECKs for
them eventually.
This option disables any attempts in configure to create dependency on
stuff requiring linking to librt.so and libpthread.so, in this case this
means clock_gettime(CLOCK_MONOTONIC, &mt).
We were in need to build curl which doesn't link libpthread.so to avoid
the following bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=16628.
The latest version(s) of the icc compiler no longer accept the extra
space in the -we (warning enable), -wd (warning disable), etc.
Reported-by: Elmira A Semenova
Bug: http://curl.haxx.se/mail/lib-2013-09/0182.html
