From: "Timur Safin" <tsafin@tarantool.org> To: 'Vladislav Shpilevoy' <v.shpilevoy@tarantool.org>, tarantool-patches@dev.tarantool.org, avtikhon@tarantool.org Subject: Re: [Tarantool-patches] [PATCH 1/1] build: turn off LTO for exports.c Date: Wed, 20 May 2020 10:26:48 +0300 [thread overview] Message-ID: <384c01d62e78$066824d0$13386e70$@tarantool.org> (raw) In-Reply-To: <a7442474017849f773fc0470c14df3845b9c84ab.1589931033.git.v.shpilevoy@tarantool.org> Yup, let's hack a problem with using hack! (Though using entirely hacking approaches in this particular case is most consistent) LGTM Timur : -----Original Message----- : From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> : 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 : : There were lots of errors of kind: : : /builds/M4RrgQZ3/0/tarantool/tarantool/src/exports.h:395:1: error: : variable ‘uuid_nil’ 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; : : 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 : : extern void <symbol>(void); : : 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. : : 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. : : This was the case for variables: : - uuid_nil : - tarantool_lua_ibuf : - log_pid : - log_format : - crc32_calc : - _say : - log_level : : 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. : : Closes #5001 : --- : Branch: http://github.com/tarantool/tarantool/tree/gerold103/gh-5001-lto- : exports-fnolto : Issue: https://github.com/tarantool/tarantool/issues/5001 : : src/CMakeLists.txt | 13 +++++++++++++ : 1 file changed, 13 insertions(+) : : 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() : : +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)
next prev parent reply other threads:[~2020-05-20 7:26 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-05-19 23:31 Vladislav Shpilevoy 2020-05-20 7:26 ` Timur Safin [this message] 2020-05-25 17:13 ` Alexander V. Tikhonov 2020-05-25 19:02 ` Vladislav Shpilevoy
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='384c01d62e78$066824d0$13386e70$@tarantool.org' \ --to=tsafin@tarantool.org \ --cc=avtikhon@tarantool.org \ --cc=tarantool-patches@dev.tarantool.org \ --cc=v.shpilevoy@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH 1/1] build: turn off LTO for exports.c' \ /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