From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp38.i.mail.ru (smtp38.i.mail.ru [94.100.177.98]) (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 09CE7445320 for ; Wed, 8 Jul 2020 22:22:46 +0300 (MSK) Date: Wed, 8 Jul 2020 22:22:00 +0300 From: Alexander Turenko Message-ID: <20200708192200.vwd7thsmsjurdtql@tkn_work_nb> References: <81870339991bd3f54fc532b631f48d8bf4aa2b57.1594039762.git.avtikhon@tarantool.org> <20200708113726.GH5559@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200708113726.GH5559@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH v1] Block linker flag '--no-undefined' List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Munkin Cc: tarantool-patches@dev.tarantool.org > Minor: I reworded the message a bit: > | Found that OpenSUSE toolchain adds '--no-undefined' linked flag leading Typo: linked -> linker. > Strictly saying, I see no reason to fix the problem here. These changes > are similar and one ought to add this "woodoo magic" line to every > CMakeLists.txt used for building dynamic libraries using Lua C API. > Since we are using to build these extensions can you make > this change there? I missed this way. It should work, but we should care about not leaving a test/foo subdirectory scope. I think it should be verified manually. I would even add a comment regarding the macro behaviour: it affects current cmake variable scope and so a user should care to don't use it in a top level scope. Sadly, we cannot solve the problem with properties, because flags from the LINK_FLAGS target property are added before CMAKE_SHARED_LINKER_FLAGS flags and because there is no --no-undefined counterpart linker option (there is `--undefined foo` to allow certain symbols to be undefined, but is not what we need here). WBR, Alexander Turenko.