From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp49.i.mail.ru (smtp49.i.mail.ru [94.100.177.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 23C34469710 for ; Wed, 20 May 2020 10:26:51 +0300 (MSK) From: "Timur Safin" References: In-Reply-To: Date: Wed, 20 May 2020 10:26:48 +0300 Message-ID: <384c01d62e78$066824d0$13386e70$@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: ru Subject: Re: [Tarantool-patches] [PATCH 1/1] build: turn off LTO for exports.c List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Vladislav Shpilevoy' , tarantool-patches@dev.tarantool.org, avtikhon@tarantool.org Yup, let's hack a problem with using hack!=20 (Though using entirely hacking approaches in this particular case is most consistent) LGTM Timur : -----Original Message----- : From: Vladislav Shpilevoy : Sent: Wednesday, May 20, 2020 2:31 AM : To: tarantool-patches@dev.tarantool.org; tsafin@tarantool.org; : avtikhon@tarantool.org : Subject: [PATCH 1/1] build: turn off LTO for exports.c :=20 : There were lots of errors of kind: :=20 : /builds/M4RrgQZ3/0/tarantool/tarantool/src/exports.h:395:1: error: : variable =E2=80=98uuid_nil=E2=80=99 redeclared as function : EXPORT(uuid_nil) : ^ : /builds/M4RrgQZ3/0/tarantool/tarantool/src/lib/uuid/tt_uuid.c:39:22: : note: previously declared here : const struct tt_uuid uuid_nil; :=20 : when LTO was enabled. That happened because exports.c file, to : take symbol addresses, declared lots of functions and variables : from all the code base as :=20 : extern void (void); :=20 : This is crazy, but it worked for normal builds. Because symbol is : symbol. The compilers couldn't find conflicting declarations, : because they never met in one compilation unit. :=20 : However the lie was revealed by linker with LTO enabled. It could : see, that actual symbol definitions didn't match their exports in : exports.c. It could live with mismatching function-function or : variable-variable cases, but couldn't withstand function-variable : mismatches. When a symbol was declared as a variable in one place : and as a function in another. :=20 : This was the case for variables: : - uuid_nil : - tarantool_lua_ibuf : - log_pid : - log_format : - crc32_calc : - _say : - log_level :=20 : The errors were false positive, because the symbols were never : used for anything except taking their addresses. To calm the : linker down exports.c now does not participate in LTO. :=20 : Closes #5001 : --- : Branch: = http://github.com/tarantool/tarantool/tree/gerold103/gh-5001-lto- : exports-fnolto : Issue: https://github.com/tarantool/tarantool/issues/5001 :=20 : src/CMakeLists.txt | 13 +++++++++++++ : 1 file changed, 13 insertions(+) :=20 : diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt : index 7a718fde9..c2fb7841c 100644 : --- a/src/CMakeLists.txt : +++ b/src/CMakeLists.txt : @@ -246,6 +246,19 @@ if(BUILD_STATIC) : endif() : endif() :=20 : +if (ENABLE_LTO) : + # Exports compilation unit is entirely a hack. It references : + # symbols among static libraries and object files declaring : + # them all as functions. To avoid header dependencies. This is : + # not detected by the compilers, since they never see : + # conflicting definitions in one compilation unit. But this : + # makes LTO mad, because the linker sees all the definitions, : + # and is especially angry when a variable is declared as a : + # function. To get rid of these false positive errors the : + # exports file is not link-time optimized. : + set_source_files_properties(exports.c PROPERTIES COMPILE_FLAGS = -fno- : lto) : +endif() : + : add_executable( : tarantool main.cc exports.c : ${LIBUTIL_FREEBSD_SRC}/flopen.c : -- : 2.21.1 (Apple Git-122.3)