So gnulib provides macros to wrap the attribute visibility default stuff? This is neat. I'm a bit concerned about the "Note
that the precise control of the exported symbols will not work with other compilers than GCC >= 4.0,"I assume this will work with clang. Is this as compatible as relying on libtool for controlling symbol export?
Cheers,
Daniel
P.S.: apologies for double posting. I didn't realize that my first post went through despite not having subscribed to the list yet...
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
>