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
The compiler test used a variable before it was assigned when it tried
to see how it acts on a mismatching prototype, which could cause a false
positive.
Instead of claiming it is an error, we call it a "note" to reduce the
severity level. But the following text now says the [variable] "*should*
only be used to specify"... instead of previously having said "may".
This function was only used twice, both in places where performance
isn't crucial (socks + if2ip). Removing the use of this function removes
the need to have our private version for systems without it == reduced
amount of code.
Also, in the SOCKS case it is clearly better to fail gracefully rather
than to truncate the results.
This work was triggered by a bug report on the strcal prototype in
strequal.h.
strlcat was added in commit db70cd28 in February 2001!
Bug: http://curl.haxx.se/bug/view.cgi?id=1192
Reported by: Jeremy Huddleston
- Take into account that 'wc' may return leading spaces.
- Set internationalization behavior variables.
Tor Arntsen analyzed and reported the issue.
URL: http://curl.haxx.se/mail/lib-2013-01/0351.html
Some basic checks we make were placed early enough in generated
configure script when using autoconf 2.5X versions. Newer autoconf
versions expand these checks much further into the configure script,
rendering them useless. Using XC_CONFIGURE_PREAMBLE fixes placement
of early intended checks across all our autoconf supported versions.
Notes:
When running a configure script that has nested packages (for example
libcurl's configure with --enable-ares and c-ares sources embedded in
curl tree) and AC_CONFIG_SUBDIRS([nested-subdir]) machinery is used to
automatically run the nested configure script from within the parent
configure script, it happens that the nested _shell_ script will
inherit shell variables exported from the parent _shell_ script.
If for example parent configure script sets and exports LDFLAGS and LIBS
variables with proper values in order to link either a parent library or
program with a library which will be configured and built by a nested
package; It will happen that when the nested configure script runs, the
nested library does not exist yet and _any_ link-test done in the nested
configure will fail, such as those that autoconf macros perform in order
to detect existing compiler and its characteristics, the result is that
the nested configure script will fail with errors such as:
configure: error: C compiler cannot create executables
For now, we no longer export variables previously exported here.
On the other hand, AC_SUBST'ing them is appropriate and even with nested
packages each package's config.status gets its own package values.
So we reinstate AC_SUBST'ing previously AC_SUBST'ed variables.
Tested with:
buildconf: autoconf version 2.69
buildconf: autom4te version 2.69
buildconf: autoheader version 2.69
buildconf: automake version 1.13.1
buildconf: aclocal version 1.13.1
buildconf: libtool version 2.4
buildconf: GNU m4 version 1.4.16
This commit renames lib/setup.h to lib/curl_setup.h and
renames lib/setup_once.h to lib/curl_setup_once.h.
Removes the need and usage of a header inclusion guard foreign
to libcurl. [1]
Removes the need and presence of an alarming notice we carried
in old setup_once.h [2]
----------------------------------------
1 - lib/setup_once.h used __SETUP_ONCE_H macro as header inclusion guard
up to commit ec691ca3 which changed this to HEADER_CURL_SETUP_ONCE_H,
this single inclusion guard is enough to ensure that inclusion of
lib/setup_once.h done from lib/setup.h is only done once.
Additionally lib/setup.h has always used __SETUP_ONCE_H macro to
protect inclusion of setup_once.h even after commit ec691ca3, this
was to avoid a circular header inclusion triggered when building a
c-ares enabled version with c-ares sources available which also has
a setup_once.h header. Commit ec691ca3 exposes the real nature of
__SETUP_ONCE_H usage in lib/setup.h, it is a header inclusion guard
foreign to libcurl belonging to c-ares's setup_once.h
The renaming this commit does, fixes the circular header inclusion,
and as such removes the need and usage of a header inclusion guard
foreign to libcurl. Macro __SETUP_ONCE_H no longer used in libcurl.
2 - Due to the circular interdependency of old lib/setup_once.h and the
c-ares setup_once.h header, old file lib/setup_once.h has carried
back from 2006 up to now days an alarming and prominent notice about
the need of keeping libcurl's and c-ares's setup_once.h in sync.
Given that this commit fixes the circular interdependency, the need
and presence of mentioned notice is removed.
All mentioned interdependencies come back from now old days when
the c-ares project lived inside a curl subdirectory. This commit
removes last traces of such fact.
This reverts renaming and usage of lib/*.h header files done
28-12-2012, reverting 2 commits:
f871de0... build: make use of 76 lib/*.h renamed files
ffd8e12... build: rename 76 lib/*.h files
This also reverts removal of redundant include guard (redundant thanks
to changes in above commits) done 2-12-2013, reverting 1 commit:
c087374... curl_setup.h: remove redundant include guard
This also reverts renaming and usage of lib/*.c source files done
3-12-2013, reverting 3 commits:
13606bb... build: make use of 93 lib/*.c renamed files
5b6e792... build: rename 93 lib/*.c files
7d83dff... build: commit 13606bbfde follow-up 1
Start of related discussion thread:
http://curl.haxx.se/mail/lib-2013-01/0012.html
Asking for confirmation on pushing this revertion commit:
http://curl.haxx.se/mail/lib-2013-01/0048.html
Confirmation summary:
http://curl.haxx.se/mail/lib-2013-01/0079.html
NOTICE: The list of 2 files that have been modified by other
intermixed commits, while renamed, and also by at least one
of the 6 commits this one reverts follows below. These 2 files
will exhibit a hole in history unless git's '--follow' option
is used when viewing logs.
lib/curl_imap.h
lib/curl_smtp.h
Provide a 'traceable' AC_CONFIG_MACRO_DIR definition only when using
an autoconf version that does not provide it, instead of what we were
doing up to now of providing and overriding AC_CONFIG_MACRO_DIR for
all autoconf versions.
When nothing is told to configure, we should not enforce switching off
debug options with -g0 (or similar). We instead don't use -g at all in
that situaion and therefore allow the user's CFLAGS settings possibly
dictate what to do.
Removing this option as it currently only functions to lure people into
wrongly using it and falsely believing that libcurl will work fine
without using nonblocking sockets internally - which leads to hard to
track or understand errors.
Currently it is unknown if there is any version of clang that
actually supports -Wstrict-aliasing. What is known is that there
are several that don't support it.
configure script now provides conditional definitions for Makefile.am
that result in CURL_HIDDEN_SYMBOLS being defined by resulting makefiles
when appropriate.
Additionally, configure script option for symbol hiding control is now
named --enable-symbol-hiding --disable-symbol-hiding. While still valid,
old option name --enable-hidden-symbols --disable-hidden-symbols will
be deprecated in some future release.
Take in account that POSIX standard Issue 7 drops h_errno support. Now, we also
consider getaddrinfo() to be thread-safe when (_POSIX_C_SOURCE >= 200809L) or
(_XOPEN_SOURCE >= 700) independently of whether h_errno exists or not.
Daniel Stenberg