lightning
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LibJIT / Lightning interoperability issue


From: Marc Nieper-Wißkirchen
Subject: Re: LibJIT / Lightning interoperability issue
Date: Sun, 27 Dec 2020 11:25:41 +0100

Gnulib has a way to easily solve this issue:
https://www.gnu.org/software/gnulib/manual/html_node/Exported-Symbols-of-Shared-Libraries.html#Exported-Symbols-of-Shared-Libraries

Adding Gnulib to Lightning would make sense in the long run anyway,
and due to the way Gnulib is intended to be used, this doesn't add any
runtime dependency.

Marc

Am So., 27. Dez. 2020 um 02:58 Uhr schrieb Daniel Schwen <lists@schwen.de>:
>
> 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.
>
> Cheers,
> Daniel
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]