[Tarantool-patches] [PATCH 1/1] build: turn off LTO for exports.c
Timur Safin
tsafin at tarantool.org
Wed May 20 10:26:48 MSK 2020
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 at tarantool.org>
: Sent: Wednesday, May 20, 2020 2:31 AM
: To: tarantool-patches at dev.tarantool.org; tsafin at tarantool.org;
: avtikhon at 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)
More information about the Tarantool-patches
mailing list