* [Tarantool-patches] [PATCH] build: link bundled libcurl with c-ares
@ 2019-11-25 13:53 Serge Petrenko
2019-12-18 2:33 ` Alexander Turenko
0 siblings, 1 reply; 4+ messages in thread
From: Serge Petrenko @ 2019-11-25 13:53 UTC (permalink / raw)
To: alexander.turenko; +Cc: tarantool-patches
libcurl has a built-in threaded resolver used for asynchronous DNS
requests, however, when DNS server is slow to respond, the request still
hangs tarantool until it is finished. The reason is that curl calls
thread_join on the resolving thread internally upon timeout, making the
calling thread hang until resolution has ended.
Use c-ares as an asynchronous resolver instead to eliminate the problem.
Closes #4591
---
https://github.com/tarantool/tarantool/issues/4591
https://github.com/tarantool/tarantool/tree/sp/gh-4591-link-curl-with-c-ares-full-ci
.gitmodules | 3 ++
CMakeLists.txt | 6 ++++
cmake/BuildAres.cmake | 67 ++++++++++++++++++++++++++++++++++++++++
cmake/BuildLibCURL.cmake | 31 +++++++++++++++++--
third_party/c-ares | 1 +
5 files changed, 106 insertions(+), 2 deletions(-)
create mode 100644 cmake/BuildAres.cmake
create mode 160000 third_party/c-ares
diff --git a/.gitmodules b/.gitmodules
index 76303e0c5..d45e9ce8b 100644
--- a/.gitmodules
+++ b/.gitmodules
@@ -40,3 +40,6 @@
[submodule "third_party/curl"]
path = third_party/curl
url = https://github.com/tarantool/curl.git
+[submodule "third_party/c-ares"]
+ path = third_party/c-ares
+ url = https://github.com/tarantool/c-ares.git
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 7d6c0846e..dca060857 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -339,7 +339,13 @@ endif()
# Curl
#
option(ENABLE_BUNDLED_LIBCURL "Enable building of the bundled libcurl" ON)
+option(BUNDLED_LIBCURL_USE_ARES "Build curl with bundled c-ares"
+ ${ENABLE_BUNDLED_LIBCURL})
if (ENABLE_BUNDLED_LIBCURL)
+ if(BUNDLED_LIBCURL_USE_ARES)
+ include(BuildAres)
+ ares_build()
+ endif()
include(BuildLibCURL)
curl_build()
add_dependencies(build_bundled_libs bundled-libcurl)
diff --git a/cmake/BuildAres.cmake b/cmake/BuildAres.cmake
new file mode 100644
index 000000000..ea4cfdd9d
--- /dev/null
+++ b/cmake/BuildAres.cmake
@@ -0,0 +1,67 @@
+# A macro to build the bundled libcares
+macro(ares_build)
+ set(ARES_SOURCE_DIR ${PROJECT_SOURCE_DIR}/third_party/c-ares)
+ set(ARES_BINARY_DIR ${PROJECT_BINARY_DIR}/build/ares/work)
+ set(ARES_INSTALL_DIR ${PROJECT_BINARY_DIR}/build/ares/dest)
+
+ # See BuildLibCURL.cmake for details.
+ set(ARES_CPPFLAGS "")
+ set(ARES_CFLAGS "")
+ set(ARES_CXXFLAGS "")
+ if (TARGET_OS_DARWIN AND NOT "${CMAKE_OSX_SYSROOT}" STREQUAL "")
+ set(ARES_CPPFLAGS "${ARES_CPPFLAGS} ${CMAKE_C_SYSROOT_FLAG} ${CMAKE_OSX_SYSROOT}")
+ set(ARES_CFLAGS "${ARES_CFLAGS} ${CMAKE_C_SYSROOT_FLAG} ${CMAKE_OSX_SYSROOT}")
+ set(ARES_CXXFLAGS "${ARES_CXXFLAGS} ${CMAKE_CXX_SYSROOT_FLAG} ${CMAKE_OSX_SYSROOT}")
+ endif()
+
+ include(ExternalProject)
+ ExternalProject_Add(
+ bundled-ares-project
+ SOURCE_DIR ${ARES_SOURCE_DIR}
+ PREFIX ${ARES_INSTALL_DIR}
+ DOWNLOAD_DIR ${ARES_BINARY_DIR}
+ TMP_DIR ${ARES_BINARY_DIR}/tmp
+ STAMP_DIR ${ARES_BINARY_DIR}/stamp
+ BINARY_DIR ${ARES_BINARY_DIR}
+ CONFIGURE_COMMAND
+ cd <SOURCE_DIR> && ./buildconf &&
+ cd <BINARY_DIR> && <SOURCE_DIR>/configure
+ # Pass the same toolchain as is used to build
+ # tarantool itself, because they can be
+ # incompatible.
+ CC=${CMAKE_C_COMPILER}
+ CXX=${CMAKE_CXX_COMPILER}
+ LD=${CMAKE_LINKER}
+ AR=${CMAKE_AR}
+ RANLIB=${CMAKE_RANLIB}
+ NM=${CMAKE_NM}
+ STRIP=${CMAKE_STRIP}
+
+ CFLAGS=${ARES_CFLAGS}
+ CPPFLAGS=${ARES_CPPFLAGS}
+ CXXFLAGS=${ARES_CXXFLAGS}
+ # Pass empty LDFLAGS to discard using of
+ # corresponding environment variable.
+ # It is possible that a linker flag assumes that
+ # some compilation flag is set. We don't pass
+ # CFLAGS from environment, so we should not do it
+ # for LDFLAGS too.
+ LDFLAGS=
+
+ --prefix=<INSTALL_DIR>
+ --enable-static
+
+ BUILD_COMMAND cd <BINARY_DIR> && $(MAKE)
+ INSTALL_COMMAND cd <BINARY_DIR> && $(MAKE) install)
+
+ add_library(bundled-ares STATIC IMPORTED GLOBAL)
+ set_target_properties(bundled-ares PROPERTIES IMPORTED_LOCATION
+ ${ARES_INSTALL_DIR}/lib/libcares.a)
+ add_dependencies(bundled-ares bundled-ares-project)
+
+ unset(ARES_CPPFLAGS)
+ unset(ARES_CFLAGS)
+ unset(ARES_CXXFLAGS)
+ unset(ARES_BINARY_DIR)
+ unset(ARES_SOURCE_DIR)
+endmacro(ares_build)
diff --git a/cmake/BuildLibCURL.cmake b/cmake/BuildLibCURL.cmake
index 6d40ab045..756297878 100644
--- a/cmake/BuildLibCURL.cmake
+++ b/cmake/BuildLibCURL.cmake
@@ -19,6 +19,21 @@ macro(curl_build)
get_filename_component(FOUND_OPENSSL_ROOT_DIR ${OPENSSL_INCLUDE_DIR} DIRECTORY)
set(LIBCURL_OPENSSL_OPT "--with-ssl=${FOUND_OPENSSL_ROOT_DIR}")
+ # Use either c-ares bundled with tarantool or
+ # libcurl-default threaded resolver.
+ if(BUNDLED_LIBCURL_USE_ARES)
+ set(ASYN_DNS_USED "ares")
+ set(ASYN_DNS_UNUSED "threaded-resolver")
+ set(ASYN_DNS_PATH "=${ARES_INSTALL_DIR}")
+ else()
+ set(ASYN_DNS_USED "threaded-resolver")
+ set(ASYN_DNS_UNUSED "ares")
+ set(ASYN_DNS_PATH "")
+ endif()
+
+ set(ENABLED_DNS_OPT "--enable-${ASYN_DNS_USED}${ASYN_DNS_PATH}")
+ set(DISABLED_DNS_OPT "--disable-${ASYN_DSN_UNUSED}")
+
# Pass -isysroot=<SDK_PATH> option on Mac OS to a preprocessor
# and a C compiler to find header files installed with an SDK.
#
@@ -100,17 +115,17 @@ macro(curl_build)
--without-zsh-functions-dir
--without-fish-functions-dir
+ ${ENABLED_DNS_OPT}
--enable-http
--enable-proxy
--enable-ipv6
- --enable-threaded-resolver
--enable-unix-sockets
--enable-cookies
--enable-http-auth
--enable-mime
--enable-dateparse
- --disable-ares
+ ${DISABLED_DNS_OPT}
--disable-ftp
--disable-file
--disable-ldap
@@ -140,14 +155,26 @@ macro(curl_build)
add_library(bundled-libcurl STATIC IMPORTED GLOBAL)
set_target_properties(bundled-libcurl PROPERTIES IMPORTED_LOCATION
${LIBCURL_INSTALL_DIR}/lib/libcurl.a)
+ if (BUNDLED_LIBCURL_USE_ARES)
+ # Need to build ares first
+ add_dependencies(bundled-libcurl-project bundled-ares)
+ endif()
add_dependencies(bundled-libcurl bundled-libcurl-project)
set(CURL_INCLUDE_DIRS ${LIBCURL_INSTALL_DIR}/include)
set(CURL_LIBRARIES bundled-libcurl ${LIBZ_LIBRARY})
+ if (BUNDLED_LIBCURL_USE_ARES)
+ set(CURL_LIBRARIES ${CURL_LIBRARIES} bundled-ares)
+ endif()
if (TARGET_OS_LINUX OR TARGET_OS_FREEBSD)
set(CURL_LIBRARIES ${CURL_LIBRARIES} rt)
endif()
+ unset(ASYN_DNS_USED)
+ unset(ASYN_DNS_UNUSED)
+ unset(ASYN_DNS_PATH)
+ unset(ENABLED_DNS_OPT)
+ unset(DISABLED_DNS_OPT)
unset(LIBCURL_CPPFLAGS)
unset(LIBCURL_CFLAGS)
unset(FOUND_OPENSSL_ROOT_DIR)
diff --git a/third_party/c-ares b/third_party/c-ares
new file mode 160000
index 000000000..14e38b154
--- /dev/null
+++ b/third_party/c-ares
@@ -0,0 +1 @@
+Subproject commit 14e38b154c972cd41fed277e6f5c4fc8f0ed8d9f
--
2.21.0 (Apple Git-122)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Tarantool-patches] [PATCH] build: link bundled libcurl with c-ares
2019-11-25 13:53 [Tarantool-patches] [PATCH] build: link bundled libcurl with c-ares Serge Petrenko
@ 2019-12-18 2:33 ` Alexander Turenko
2020-01-21 12:17 ` Serge Petrenko
0 siblings, 1 reply; 4+ messages in thread
From: Alexander Turenko @ 2019-12-18 2:33 UTC (permalink / raw)
To: Serge Petrenko; +Cc: tarantool-patches
I brief: I would compare build times of c-ares with `./configure && make
-j` against `cmake . && make -j` and let's start with using ./configure
if the difference is not significant, but otherwise use CMake from
beginning.
See other thoughts below.
WBR, Alexander Turenko.
----
I guess that src/CMakeLists.txt will give a warning on static build: see
around `${libstatic} STREQUAL bundled-libcurl` line.
I also guess that using CMake for luajit, curl and c-ares may solve
several problems: build time, passing toolchain and Mac OS specific
flags, handling -DCMAKE_BUILD_TYPE in subprojects, clean out-of-source
build. Let's verify at least build time: if ./configure adds much time,
then we'll make other developers angry. Maybe it worth to use CMake for
c-ares from begnning.
Don't sure whether it worth to copy CMakeLists.txt from c-ares to our
cmake/ directory. Let's start w/o copy and consider to do it if we'll
need to change something.
I don't sure which pros and cons have using of ExternalProject(), it
seems we should look a bit into this.
I also don't sure whether tarantool-specific flags will be passed for
c-ares when we'll use CMake (with / without ExternalProject()). Some of
them we should pass (such as -UNDEBUG that is set by
-DCMAKE_BUILD_TYPE=Debug), some maybe not (need to verify
add_compile_flags() macro calls at least).
Sergey V. will work on
https://github.com/tarantool/tarantool/issues/4444 , maybe it worth to
cooperate. (CCed him.)
Is c-ares depends on some libraries?
WBR, Alexander Turenko.
On Mon, Nov 25, 2019 at 04:53:47PM +0300, Serge Petrenko wrote:
> libcurl has a built-in threaded resolver used for asynchronous DNS
> requests, however, when DNS server is slow to respond, the request still
> hangs tarantool until it is finished. The reason is that curl calls
> thread_join on the resolving thread internally upon timeout, making the
> calling thread hang until resolution has ended.
> Use c-ares as an asynchronous resolver instead to eliminate the problem.
>
> Closes #4591
> ---
> https://github.com/tarantool/tarantool/issues/4591
> https://github.com/tarantool/tarantool/tree/sp/gh-4591-link-curl-with-c-ares-full-ci
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Tarantool-patches] [PATCH] build: link bundled libcurl with c-ares
2019-12-18 2:33 ` Alexander Turenko
@ 2020-01-21 12:17 ` Serge Petrenko
2020-02-08 19:28 ` Alexander Turenko
0 siblings, 1 reply; 4+ messages in thread
From: Serge Petrenko @ 2020-01-21 12:17 UTC (permalink / raw)
To: Alexander Turenko; +Cc: tarantool-patches
> 18 дек. 2019 г., в 5:33, Alexander Turenko <alexander.turenko@tarantool.org> написал(а):
>
> I brief: I would compare build times of c-ares with `./configure && make
> -j` against `cmake . && make -j` and let's start with using ./configure
> if the difference is not significant, but otherwise use CMake from
> beginning.
>
> See other thoughts below.
>
> WBR, Alexander Turenko.
>
> ——
Hi! Thank you for review!
I sent v2 and fixed what you’ve pointed out.
>
> I guess that src/CMakeLists.txt will give a warning on static build: see
> around `${libstatic} STREQUAL bundled-libcurl` line.
Fixed.
>
> I also guess that using CMake for luajit, curl and c-ares may solve
> several problems: build time, passing toolchain and Mac OS specific
> flags, handling -DCMAKE_BUILD_TYPE in subprojects, clean out-of-source
> build. Let's verify at least build time: if ./configure adds much time,
> then we'll make other developers angry. Maybe it worth to use CMake for
> c-ares from begnning.
I’ve done that, and you’re right.
Here are `time (cmake . && make -j)` outputs
when using configure for c-ares
real 3m16.989s
user 4m45.145s
sys 1m45.434s
and cmake, respectively
real 2m2.913s
user 3m55.688s
sys 1m17.485s
>
> Don't sure whether it worth to copy CMakeLists.txt from c-ares to our
> cmake/ directory. Let's start w/o copy and consider to do it if we'll
> need to change something.
>
> I don't sure which pros and cons have using of ExternalProject(), it
> seems we should look a bit into this.
>
You see, we need c-ares installed, since curl depends on an existing c-ares
installation. So, curl requires that c-ares is installed on build step already.
We cannot use add_subdirectory. It will make cmake run build steps for all the
subdirs first, and only then install them.
ExternalProject_Add does exactly what we need. It runs both build and install
steps of the external project on parent’s build step.
> I also don't sure whether tarantool-specific flags will be passed for
> c-ares when we'll use CMake (with / without ExternalProject()). Some of
> them we should pass (such as -UNDEBUG that is set by
> -DCMAKE_BUILD_TYPE=Debug), some maybe not (need to verify
> add_compile_flags() macro calls at least).
All the cmake options need to be passed to external project explicitly.
>
> Sergey V. will work on
> https://github.com/tarantool/tarantool/issues/4444 , maybe it worth to
> cooperate. (CCed him.)
>
> Is c-ares depends on some libraries?
CMakeLists.txt extract:
# Tell C-Ares about libraries to depend on
IF (HAVE_LIBRESOLV)
LIST (APPEND CARES_DEPENDENT_LIBS resolv)
ENDIF ()
IF (HAVE_LIBNSL)
LIST (APPEND CARES_DEPENDENT_LIBS nsl)
ENDIF ()
IF (HAVE_LIBSOCKET)
LIST (APPEND CARES_DEPENDENT_LIBS socket)
ENDIF ()
IF (HAVE_LIBRT)
LIST (APPEND CARES_DEPENDENT_LIBS rt)
ENDIF ()
>
> WBR, Alexander Turenko.
>
> On Mon, Nov 25, 2019 at 04:53:47PM +0300, Serge Petrenko wrote:
>> libcurl has a built-in threaded resolver used for asynchronous DNS
>> requests, however, when DNS server is slow to respond, the request still
>> hangs tarantool until it is finished. The reason is that curl calls
>> thread_join on the resolving thread internally upon timeout, making the
>> calling thread hang until resolution has ended.
>> Use c-ares as an asynchronous resolver instead to eliminate the problem.
>>
>> Closes #4591
>> ---
>> https://github.com/tarantool/tarantool/issues/4591
>> https://github.com/tarantool/tarantool/tree/sp/gh-4591-link-curl-with-c-ares-full-ci
--
Serge Petrenko
sergepetrenko@tarantool.org
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Tarantool-patches] [PATCH] build: link bundled libcurl with c-ares
2020-01-21 12:17 ` Serge Petrenko
@ 2020-02-08 19:28 ` Alexander Turenko
0 siblings, 0 replies; 4+ messages in thread
From: Alexander Turenko @ 2020-02-08 19:28 UTC (permalink / raw)
To: Serge Petrenko; +Cc: tarantool-patches
Oh, so weird world of build systems. I tried to understand how
everything should work, what is flawed on c-ares build system side and
on our side. This description becomes large, so I'll summarize what
actions I expect from you:
* File an issue against c-ares that CMake script should not add
unnecessary libraries (./configure does not do that).
* Add empty CARES_LIBRARIES (with proper FIXME comment) and add it to
CURL_LIBRARIES.
----
> > Is c-ares depends on some libraries?
>
> CMakeLists.txt extract:
Having dependent libraries opens several questions that we should verify
for each of those libs:
1. Is it possible that the library exists on a build system, but may be
missed on a target system. A build system may be one where we build a
package (Deb, RPM, brew bottle, FreeBSD binary package), a target
system is where tarantool is installed from the package.
2. If a library on which our static library (c-ares) depends is not an
integral part of a system, then we should add it to dependencies of
packages and link the transitive dependency statically when doing a
static build of tarantool.
> # Tell C-Ares about libraries to depend on
> IF (HAVE_LIBRESOLV)
> LIST (APPEND CARES_DEPENDENT_LIBS resolv)
> ENDIF ()
It is for iPhone targets (see [1]), so we can don't bother with that.
[1]: https://github.com/c-ares/c-ares/commit/affc63cba875df11daade6f6767cb06e013ac6c3
> IF (HAVE_LIBNSL)
> LIST (APPEND CARES_DEPENDENT_LIBS nsl)
> ENDIF ()
It just adds -lnsl at linking (there are no ifdefs that depends on this
flag). I guess it is only to borrow gethostbyname() and maybe other
network related functions, which is part of libc.
Points:
* Old glibc ships gethostbyname() in libnsl.so, but now it is right in
libc.so.
* There is modern separate libnsl (see [2]), which supports IPv6.
* -lnsl is not added by ./configure if gethostbyname() is available w/o
it.
* gethostbyname() is used only in adig.c and we anyway disable tools with
-DCARES_BUILD_TOOLS=OFF. Don't sure about other functions from this
library.
I would work around CMake logic to stick with ./configure logic: add
-lnsl only when gethostbyname() is not availiable w/o it. After this
we'll build c-ares with -lnsl only when libnsl.so is the integral part
of a distro and so both build and install system should have it.
(Update: tarantool executable is linked w/o libnsl.so, so this may be
ignored.)
Let's file an issue to c-ares, which will show different default
behaviour of cmake and configure.
BTW, grpc even disabled this unconditionally, see [3] and [4].
[2]: https://github.com/thkukuk/libnsl
[3]: https://github.com/grpc/grpc/issues/17255
[4]: https://github.com/grpc/grpc/blob/e83426b741d21b744c111109dbac899d6e99b4d7/cmake/cares.cmake#L23
> IF (HAVE_LIBSOCKET)
> LIST (APPEND CARES_DEPENDENT_LIBS socket)
> ENDIF ()
It seems it is mostly the same as libnsl: usually don't needed and
should be enable only when necessary and is a part of a system. There
are no however separate library with the same name (I didn't find any)
and so enabling it when it exists looks more or less safe.
So no actions is necessary from our side, however I would anyway mention
in the issue (which I proposed to send above) that it would be better to
enable it only when there are no getaddrinfo() right inside libc.so.
> IF (HAVE_LIBRT)
> LIST (APPEND CARES_DEPENDENT_LIBS rt)
> ENDIF ()
c-ares cmake file doing the same bad thing here: it should check whether
clock_gettime() is available in libc.so (w/o extra libs) and only then
check for librt.so. See `man 2 clock_gettime` (cited below) and [5].
Anyway, it should be hurtless in the case, because librt.so either
exists on both build and install systems or doesn't.
From `man 2 clock_gettime`:
| Link with -lrt (only for glibc versions before 2.17).
[5]: https://github.com/tarantool/tarantool/commit/960e9c0c7ab92155842deaafb40bf240501c8145
----
Since all those libraries are system ones (except new libnsl, but we
should avoid it), static build should be fine: we don't need to add
any static libs at linking of tarantool executable.
It would be good to add all those librt.so, libsocket.so and others to
link command of tarantool executable (and possibly some unit tests) when
they're used to create libcares.a archive. This is what we doing using
CURL_LIBRARIES variable for libcurl. Everything works now, but just
because libraries that are added to libcares.so are not actually needed
on systems we have in CI.
Let's compare c-ares default libs when compiling with the configure
script and CMake on my system (I have the new libnsl installed):
Configure:
| $ ./buildconf && ./configure && make -j
| $ ldd .libs/libcares.so
| linux-vdso.so.1 (0x00007ffeaa77b000)
| libc.so.6 => /lib64/libc.so.6 (0x00007fc0ae12c000)
| /lib64/ld-linux-x86-64.so.2 (0x00007fc0ae34a000)
CMake:
| $ cmake . && make -j
| $ ldd lib/libcares.so
| linux-vdso.so.1 (0x00007ffceebd6000)
| libnsl.so.2 => /usr/lib64/libnsl.so.2 (0x00007f98321cf000)
| librt.so.1 => /lib64/librt.so.1 (0x00007f98321c5000)
| libc.so.6 => /lib64/libc.so.6 (0x00007f9831ff3000)
| libtirpc.so.3 => /lib64/libtirpc.so.3 (0x00007f9831dc8000)
| libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f9831da5000)
| /lib64/ld-linux-x86-64.so.2 (0x00007f983243a000)
NB: I didn't look why libtirpc and libpthread were added. I guess they
are not necessary too.
But tarantool executable does not have, say, libnsl.so.2 and
libtirpc.so.3 in deps (verified on commit
60d67cf38872e012f83410591dfa39140fc679e0):
| $ ldd src/tarantool
| linux-vdso.so.1 (0x00007ffeb2796000)
| libicui18n.so.65 => /usr/lib64/libicui18n.so.65 (0x00007fe4f3053000)
| libicuuc.so.65 => /usr/lib64/libicuuc.so.65 (0x00007fe4f2e74000)
| libicudata.so.65 => /usr/lib64/libicudata.so.65 (0x00007fe4f13c1000)
| libreadline.so.8 => /lib64/libreadline.so.8 (0x00007fe4f136e000)
| libncurses.so.6 => /lib64/libncurses.so.6 (0x00007fe4f1310000)
| libform.so.6 => /usr/lib64/libform.so.6 (0x00007fe4f12fd000)
| libz.so.1 => /lib64/libz.so.1 (0x00007fe4f12e1000)
| librt.so.1 => /lib64/librt.so.1 (0x00007fe4f12d7000)
| libssl.so.1.1 => /usr/lib64/libssl.so.1.1 (0x00007fe4f126a000)
| libcrypto.so.1.1 => /usr/lib64/libcrypto.so.1.1 (0x00007fe4f0ffd000)
| libdl.so.2 => /lib64/libdl.so.2 (0x00007fe4f0ff7000)
| libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe4f0fd4000)
| libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/libgcc_s.so.1 (0x00007fe4f0fb8000)
| libunwind-x86_64.so.8 => /usr/lib64/libunwind-x86_64.so.8 (0x00007fe4f0f96000)
| libunwind.so.8 => /usr/lib64/libunwind.so.8 (0x00007fe4f0f79000)
| libgomp.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/libgomp.so.1 (0x00007fe4f0f41000)
| libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/libstdc++.so.6 (0x00007fe4f0cc9000)
| libm.so.6 => /lib64/libm.so.6 (0x00007fe4f0b8b000)
| libc.so.6 => /lib64/libc.so.6 (0x00007fe4f09b7000)
| /lib64/ld-linux-x86-64.so.2 (0x00007fe4f39d9000)
| liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fe4f098e000)
So, in short:
* It is good to provide CARES_LIBRARIES, which will be added to
CURL_LIBRARIES. Even if we'll left it empty for now, it will show
proper place where to add a library if we'll need to fix a build on
some specific platform, say, Solaris.
* It would be good to get rid of all unnecessary libraries during c-ares
build, but since we ignore them anyway at tarantool build and
everything occasionally works okay on all platforms in CI, then maybe
we can leave everything as is for now.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-02-08 19:28 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-25 13:53 [Tarantool-patches] [PATCH] build: link bundled libcurl with c-ares Serge Petrenko
2019-12-18 2:33 ` Alexander Turenko
2020-01-21 12:17 ` Serge Petrenko
2020-02-08 19:28 ` Alexander Turenko
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox