[Tarantool-patches] [PATCH 00/43] Unhide symbols

[Timur Safin]

: -----Original Message-----
: From: Tarantool-patches <tarantool-patches-bounces at dev.tarantool.org> On
: Behalf Of Vladislav Shpilevoy
...

: 
: 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.

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