From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 49860250F1 for ; Thu, 15 Aug 2019 22:32:56 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id No2L0yEWnYh3 for ; Thu, 15 Aug 2019 22:32:56 -0400 (EDT) Received: from smtp3.mail.ru (smtp3.mail.ru [94.100.179.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id F29A525024 for ; Thu, 15 Aug 2019 22:32:55 -0400 (EDT) From: Alexander Turenko Subject: [tarantool-patches] [PATCH 0/2] Build libcurl statically Date: Fri, 16 Aug 2019 05:32:34 +0300 Message-Id: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: Georgy Kirichenko Cc: Alexander Turenko , tarantool-patches@freelists.org, "Alexander V . Tikhonov" , Mergen Imeev 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 CI now fails, because some SQL tests were not updated properly on master. I'll rebase the branch when it will be fixed and will ensure that everything work. Alexander Turenko (1): lua: workaround pwd.getpwall() issue on Fedora 29 Mergen Imeev (1): build: link libcurl statically from a submodule .gitmodules | 3 + .travis.mk | 8 +-- CMakeLists.txt | 12 +++- Dockerfile.staticbuild | 14 +---- cmake/BuildLibCURL.cmake | 118 +++++++++++++++++++++++++++++++++++++++ debian/control | 9 ++- rpm/tarantool.spec | 9 ++- src/CMakeLists.txt | 3 + src/lua/pwd.lua | 13 +++++ test/unit/CMakeLists.txt | 1 + third_party/curl | 1 + 11 files changed, 169 insertions(+), 22 deletions(-) create mode 100644 cmake/BuildLibCURL.cmake create mode 160000 third_party/curl -- 2.22.0