Tarantool development patches archive
 help / color / mirror / Atom feed
From: Alexander Turenko <alexander.turenko@tarantool.org>
To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>,
	"Alexander V . Tikhonov" <avtikhon@tarantool.org>,
	Kirill Yukhin <kyukhin@tarantool.org>
Cc: Yaroslav Dynnikov <yaroslav.dynnikov@tarantool.org>,
	tarantool-patches@dev.tarantool.org,
	Alexander Turenko <alexander.turenko@tarantool.org>
Subject: [Tarantool-patches] [PATCH] build: don't re-export libcurl.so/dylib symbols
Date: Wed, 30 Dec 2020 07:53:42 +0300	[thread overview]
Message-ID: <6a0b559505240475037444d82c2345a66852b8ba.1609302497.git.alexander.turenko@tarantool.org> (raw)

Export libcurl's symbols only when they are provided by tarantool
itself: when the library is linked statically into the tarantool's
executable. There is no much sense to export the symbols when we link
against the library dynamically.

Regarding motivation of the change. Since 2.6.0-36-g29ec62891 ('Ensure
all curl symbols are exported') the curl_multi_poll() function is
exported from the tarantool executable. It leads to a failure in
Homebrew's build, because there we link (dynamically) with a system
libcurl. On Mac OS 10.15 it is libcurl 7.64.1, while the function
appears since libcurl 7.66.0. So a linker reports the undefined symbol:
`curl_multi_poll`.

Now the symbols are not exported at dynamic linking with libcurl, so the
linker is happy.

This commit relaxes bounds for dynamic linking, but an attempt to link
with libcurl older than 7.66.0 statically still leads to a linking
failure. The box-tap/gh-5223-curl-exports.test.lua test still fails when
tarantool is linked (dynamically) against an old libcurl.

It looks as the good compromise. When libcurl functionality is provided
by tarantool itself, *all* functions listed in the test are present
(otherwise a linker will complain). But tarantool does not enforce a
newer libcurl version, when it just *uses* this functionality and don't
provide it for modules and stored procedured. It is not tarantool's
responsibility in the case.

We possibly should skip the box-tap/gh-5223-curl-exports.test.lua test
when tarantool is built against libcurl dynamically or revisit the
described approach. I'll leave it as possible follow up activity.

Fixes #5542
---

https://github.com/tarantool/tarantool/issues/5542
https://github.com/tarantool/tarantool/tree/Totktonada/gh-5542-dont-export-libcurl-so-symbols
Totktonada/gh-5542-dont-export-libcurl-so-symbols

 CMakeLists.txt            | 10 ++++++++++
 src/exports.c             |  2 ++
 src/exports.h             |  2 ++
 src/trivia/config.h.cmake |  2 ++
 4 files changed, 16 insertions(+)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index f0e1f5090..4fbd19558 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -397,6 +397,16 @@ else()
     find_package(CURL)
 endif()
 
+#
+# Export libcurl symbols if the library is linked statically.
+#
+if (ENABLE_BUNDLED_LIBCURL OR BUILD_STATIC)
+    set(EXPORT_LIBCURL_SYMBOLS ON)
+else()
+    set(EXPORT_LIBCURL_SYMBOLS OFF)
+endif()
+message(STATUS "EXPORT_LIBCURL_SYMBOLS: ${EXPORT_LIBCURL_SYMBOLS}")
+
 #
 # ReadLine
 #
diff --git a/src/exports.c b/src/exports.c
index a3c27143e..2a9c296a8 100644
--- a/src/exports.c
+++ b/src/exports.c
@@ -88,6 +88,8 @@
  * below. But automatically.
  */
 
+#include "trivia/config.h"
+
 /**
  * Symbol is just an address. No need to know its definition or
  * even type to get that address. Even an integer global variable
diff --git a/src/exports.h b/src/exports.h
index 2116036fa..1b95e75f6 100644
--- a/src/exports.h
+++ b/src/exports.h
@@ -130,6 +130,7 @@ EXPORT(csv_feed)
 EXPORT(csv_iterator_create)
 EXPORT(csv_next)
 EXPORT(csv_setopt)
+#ifdef EXPORT_LIBCURL_SYMBOLS
 EXPORT(curl_easy_cleanup)
 EXPORT(curl_easy_duphandle)
 EXPORT(curl_easy_escape)
@@ -211,6 +212,7 @@ EXPORT(curl_url_get)
 EXPORT(curl_url_set)
 EXPORT(curl_version)
 EXPORT(curl_version_info)
+#endif /* EXPORT_LIBCURL_SYMBOLS */
 EXPORT(decimal_unpack)
 EXPORT(error_ref)
 EXPORT(error_set_prev)
diff --git a/src/trivia/config.h.cmake b/src/trivia/config.h.cmake
index 21efb978e..38f8eb4dc 100644
--- a/src/trivia/config.h.cmake
+++ b/src/trivia/config.h.cmake
@@ -258,6 +258,8 @@
 
 #cmakedefine ENABLE_FEEDBACK_DAEMON 1
 
+#cmakedefine EXPORT_LIBCURL_SYMBOLS 1
+
 /*
  * vim: syntax=c
  */
-- 
2.25.0

             reply	other threads:[~2020-12-30  4:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-30  4:53 Alexander Turenko [this message]
2020-12-30  5:23 ` Alexander V. Tikhonov
2020-12-30  8:18 ` Kirill Yukhin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6a0b559505240475037444d82c2345a66852b8ba.1609302497.git.alexander.turenko@tarantool.org \
    --to=alexander.turenko@tarantool.org \
    --cc=avtikhon@tarantool.org \
    --cc=kyukhin@tarantool.org \
    --cc=tarantool-patches@dev.tarantool.org \
    --cc=v.shpilevoy@tarantool.org \
    --cc=yaroslav.dynnikov@tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH] build: don'\''t re-export libcurl.so/dylib symbols' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox