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

[Vladislav Shpilevoy <v.shpilevoy@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.