Tarantool development patches archive
 help / color / mirror / Atom feed
From: Kirill Yukhin <kyukhin@tarantool.org>
To: tarantool-patches@freelists.org
Cc: Georgy Kirichenko <georgy@tarantool.org>,
	Alexander Turenko <alexander.turenko@tarantool.org>,
	"Alexander V . Tikhonov" <avtikhon@tarantool.org>,
	Mergen Imeev <imeevma@tarantool.org>
Subject: [tarantool-patches] Re: [PATCH 0/2] Build libcurl statically
Date: Thu, 22 Aug 2019 11:42:04 +0300	[thread overview]
Message-ID: <20190822084204.gev377zickjwbsld@tarantool.org> (raw)
In-Reply-To: <cover.1565920130.git.alexander.turenko@tarantool.org>

Hello,

On 16 Aug 05:32, Alexander Turenko wrote:
> We decided to build libcurl statically to avoid problems with libcurl
> versions that Linux distributives ships (see the list below). I also did
> this for Mac OS and FreeBSD to provide more or less uniform build and
> dependencies list across OSes.
> 
> This patchset holds libcurl-7.65.3. AFAIK there is no problems on this
> version that affects our built-in http client. We tested this version
> (also linked statically to tarantool) against the performance
> degradation we observed by our customers on CentOS 7 (#4397) and it
> works good. The following list of issues re built-in http client will
> become unrelevant after this patchset:
> 
> * #4180 ('httpc: redirects are broken with libcurl-7.30 and older');
> * #4389 ('libcurl memory leak');
> * #4397 ('HTTPS seem to be unstable').
> 
> I didn't close them from a commit however, because it would be good to
> do a little extra work on them: at least bisect and understand what is a
> cause of a problem. Say, it is possible that a problem caused by a
> libcurl build option, but not a specific version. This information would
> be useful to be sure we really don't affected by the issues and will not
> step into the problems in the future.
> 
> The patchset contains two patches.
> 
> The first one workarounds a systemd issue that affects built-in pwd
> module when tarantool is linked against libcurl w/o GSS API support
> (this is how we build libcurl to link it statically). The problem
> appears on Fedora 29. This is prerequisite to push the second patch.
> 
> The second patch enables static libcurl build, enables it by default and
> adjusts all relevant scripts and dependencies.
> 
> https://github.com/tarantool/tarantool/issues/4318
> https://github.com/tarantool/tarantool/tree/imeevma/gh-4318-link-libcurl-statically-full-ci

I've checked the patchset into 1.10, 2.1, 2.2 and master.

--
Regards, Kirill Yukhin

      parent reply	other threads:[~2019-08-22  8:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-16  2:32 [tarantool-patches] " Alexander Turenko
2019-08-16  2:32 ` [tarantool-patches] [PATCH 1/2] lua: workaround pwd.getpwall() issue on Fedora 29 Alexander Turenko
2019-08-16  2:32 ` [tarantool-patches] [PATCH 2/2] build: link libcurl statically from a submodule Alexander Turenko
2019-08-19 22:54 ` [tarantool-patches] Re: [PATCH 0/2] Build libcurl statically Alexander Turenko
2019-08-20  7:51   ` Георгий Кириченко
2019-08-22  8:42 ` Kirill Yukhin [this message]

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=20190822084204.gev377zickjwbsld@tarantool.org \
    --to=kyukhin@tarantool.org \
    --cc=alexander.turenko@tarantool.org \
    --cc=avtikhon@tarantool.org \
    --cc=georgy@tarantool.org \
    --cc=imeevma@tarantool.org \
    --cc=tarantool-patches@freelists.org \
    --subject='[tarantool-patches] Re: [PATCH 0/2] Build libcurl statically' \
    /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