Re: LibJIT / Lightning interoperability issue

[Daniel Schwen]

Yeah, good points.

I'll look into gnulib and prepare a patch for lightning (is this the preferred way of contributing?)

Daniel

On Sun, Dec 27, 2020 at 7:57 AM Marc Nieper-Wißkirchen <marc.nieper+gnu@gmail.com> wrote:

Gnu lightning shouldn't do it differently than the rest of the Gnu
projects. Gnulib seems to be the standard. If there are any
compatibility issues, they should be resolved in Gnulib, not in the
individual projects. The Gnulib maintainers are very active and will
listen to you.

If you read the Gnulib manual page on exported symbols, you will see
that they also mention the libtool approach. I have never tried it
myself, but Gnulib seems to have a script that helps compiling a table
of symbols.

Am So., 27. Dez. 2020 um 15:48 Uhr schrieb Daniel Schwen <lists@schwen.de>:
>
> 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...
>
>
> On Sun, Dec 27, 2020, 3:25 AM Marc Nieper-Wißkirchen <marc.nieper+gnu@gmail.com> wrote:
>>
>> 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
>> >