From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp44.i.mail.ru (smtp44.i.mail.ru [94.100.177.104]) (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 41AC34696C3 for ; Thu, 16 Apr 2020 23:30:52 +0300 (MSK) 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> From: Vladislav Shpilevoy Message-ID: Date: Thu, 16 Apr 2020 22:30:47 +0200 MIME-Version: 1.0 In-Reply-To: <20200416121350.GR3072@uranus> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Cyrill Gorcunov Cc: tarantool-patches@dev.tarantool.org >>>> >>> This could be done with approach from @cyrillos, AFAIU. These functions >>> should be annotated in the code, rather than collected in a separate >>> list. >> >> Yeah, the problem is that there is no a compiler option, which would >> prevent removal of certain unused symbols defined in static libraries, >> when they are merged into one executable. > > Actually no, if symbols are reffered in executable they won't be vanished. Yeah, that is what I said - 'unused symbols', and on what my patch is based. Don't see any contradictions. >> I would happy to implement something like that but looks like it is >> not worth the complexity. > > As to me this is a way better in long term than current approach. > I like to see immediately that some symbol is exported instead of > stepping into extra/exports or whatever. 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: We not always can/want change files where symbols are defined. Timur, Sergey, Cyrill - please, realize that. 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. 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. 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. 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. 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. 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. 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. But when I want to export symbols from src/box - I can do that right in places where these symbols are defined. 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.