From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp62.i.mail.ru (smtp62.i.mail.ru [217.69.128.42]) (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 2E30A4696C3 for ; Fri, 17 Apr 2020 10:48:22 +0300 (MSK) From: "Timur Safin" References: <20200413094230.GC16266@atlas> <533bd68c-4bbb-446a-6265-da4f47d451f1@tarantool.org> <20200413194931.GB1734@tarantool.org> <8b7bcee8-b2db-8f2c-d241-687f6b6d6f4b@tarantool.org> <20200413213801.GB12552@atlas> <13d501d61286$af32d4b0$0d987e10$@tarantool.org> <20200414204127.GA32171@atlas> <2207FBB1-CFB8-4F68-BDED-8A2F4509B652@tarantool.org> <20200416121350.GR3072@uranus> In-Reply-To: Date: Fri, 17 Apr 2020 10:48:21 +0300 Message-ID: <1ce401d6148c$90eb3940$b2c1abc0$@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 00/43] Unhide symbols List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Vladislav Shpilevoy' , 'Cyrill Gorcunov' Cc: tarantool-patches@dev.tarantool.org : -----Original Message----- : From: Tarantool-patches = On : Behalf Of Vladislav Shpilevoy ... :=20 : Seems like people keep ignoring my point about us not always : being able to add the macros to the place, where a symbol is : defined. I repeat: :=20 : We not always can/want change files where symbols are : defined. Timur, Sergey, Cyrill - please, realize that. :=20 : I said it in private chats I don't know how many times already, : and in emails too. Every single attempt to bring that up was : ignored. :=20 : Some libraries, such as from third_party/, has nothing to do : with a few of their symbols needed in FFI in our src/ folder, or : considered public symbols in module.h. :=20 : For example, we want to export many things from luajit library, : because user's dynamic modules should be able to use all Lua C API : functions in their code. We can't just interfere into luajit with : our custom sections and linker scripts. It would break the module : isolation. The same can be said for all other modules not located : right inside tarantool/tarantool repository. :=20 : What if we will ever need to export something from curl? We can't : patch it, because Tarantool should be able to use vanilla curl, not : only our fork. We can't change library source code in such cases. :=20 : Or what if we ever take h2o http library? We can't just go and mark : whatever symbols we find here when we want them in FFI. We need to : export them by tarantool/tarantool means. :=20 : The only thing we can mark for export right where it is defined is : our own files in the main tarantool repository. Even submodules should : not be affected by this, such as src/lib/small. :=20 : When we want to export something from independent modules and = libraries, : we need to do that in tarantool/tarantool, in dedicated places. For : example, if I want some parts of OpenSSL exported, I should do that : where it is needed: in src/lua/digest.c. I shouldn't patch OpenSSL. :=20 : But when I want to export symbols from src/box - I can do that right : in places where these symbols are defined. :=20 : That magic macros EXPORT_API should be able to work even when we : write it not right where the symbol is defined. Like in the kernel, : from what I understand. Now I hear you, bro! Although it's possible to export symbol alias elsewhere, outside of 3rd = party codebase, and do all the dirty symbol aliasing tricks using = something similar to EXPORT* macro in kernel. But, to be honest - it's = not worth all the complexities introduced. The simple linker export = symbols list will be much simple and still serve our purposes. So for curl and openssl, at least export symbols lists look like the = preferred way here (and may be for small, but to less degree). And although, _personally_, I'd still much prefer to have our own = symbols annotated in the code with EXPORT--like macros, but it will be = inconsistent with 3rd party, and will not provide much added value. So looks like the simplest way here is to take Kostja advice and restore = original approach from ages ago. (Well with some simplifications which = we could use there to avoid unnecessary headers inclusion at the = exporting function). [It was fun to play with linker loader scripts, and learn new/old linker = tricks, but apparently the simpler approach is better here in a longer = run.] Regards, Timur=20