Re: LibJIT / Lightning interoperability issue

[Marc Nieper-Wißkirchen]

I think the idea should not be to copy a file (visibility.m4) from
Gnulib but to add Gnulib to GNU lightning so that upstream
improvements make it into GNU lightning automatically.

Am So., 27. Dez. 2020 um 17:22 Uhr schrieb Daniel Schwen <lists@schwen.de>:
>
> Ok here it is. This works for me:
>
> https://github.com/dschwen/lightning/commit/aa142a6daf44c5e1af44abbb0a0eb98d1e274ea6
>
>
>
> On Sun, Dec 27, 2020 at 8:00 AM Daniel Schwen <lists@schwen.de> wrote:
>>
>> 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
>>> >> >