Re: LibJIT / Lightning interoperability issue

[Daniel Schwen]

Yeah, this symbol export stuff is new to me, so I don't know what the best approach is. It seemed to me that relying on libtool as a compatibility layer might be better than relying on the attribute visibility default thing (which would need to be declspec in windows and would have to be switched in the public header to avoid propagating these statements into end-user code)

On Sun, Dec 27, 2020, 3:26 AM Paul Cercueil <paul@crapouillou.net> wrote:

Hi Daniel,

Le sam. 26 déc. 2020 à 18:54, Daniel Schwen <daniel@schwen.de> a
écrit :
> Hello list,
>
> I noticed that both the LibJIT as well as Lightning libraries export
> the jit_memcpy, jit_memmove, jit_realloc, and jit_free functions,
> causing crashes when linking to both.
>
> It looks like the functions are only declared in jit_private.h and not
> part of the public API, so I have tried renaming them and this fixes
> the problem:
>
> https://github.com/dschwen/lightning/commit/7bfc7f1e1857790a072ebe441b8fbc506739a873
>
> Another option would be to control symbol export in the build system,
> which I've done in this commit:
>
> https://github.com/dschwen/lightning/commit/e9ee173fc92b90deb22fa6d5abf5d31505972b0f
>
> I know this is an easy to dismiss issue, but I'm working on a generic
> mathematical _expression_ parsing library with JIT support, and I'd
> like to
> offer as many options as possible for JIT backends, and am frequently
> (actually
> always) building and linking against multiple JIT libs. It just seems
> like good
> software practice not to export unneeded symbols, as they all occupy
> one single global namespace and the more symbols you export the
> slower the link times get,

Totally with you on this one.

A third option I suggest, is to compile with -fvisibility=hidden, then
create a __api macro defined like this:
#define __api __attribute__((visibility ("default")))

Then all the public functions of the library must be prefixed with
__api.

Cheers,
-Paul