Tarantool development patches archive
 help / color / mirror / Atom feed
From: "Alexander V. Tikhonov" <avtikhon@tarantool.org>
To: Alexander Turenko <alexander.turenko@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH] build: don't re-export libcurl.so/dylib symbols
Date: Wed, 30 Dec 2020 08:23:57 +0300	[thread overview]
Message-ID: <20201230052357.GA94078@hpalx> (raw)
In-Reply-To: <6a0b559505240475037444d82c2345a66852b8ba.1609302497.git.alexander.turenko@tarantool.org>

Hi Alexander, thanks for the patch, as I see no new degradation found in
gitlab-ci testing commit criteria pipeline [1], patch LGTM.

[1] - https://gitlab.com/tarantool/tarantool/-/pipelines/235694227

On Wed, Dec 30, 2020 at 07:53:42AM +0300, Alexander Turenko wrote:
> 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  5:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-30  4:53 Alexander Turenko
2020-12-30  5:23 ` Alexander V. Tikhonov [this message]
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=20201230052357.GA94078@hpalx \
    --to=avtikhon@tarantool.org \
    --cc=alexander.turenko@tarantool.org \
    --cc=tarantool-patches@dev.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