lightning
[Top][All Lists]
Advanced

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

Re: LibJIT / Lightning interoperability issue


From: Daniel Schwen
Subject: Re: LibJIT / Lightning interoperability issue
Date: Sun, 27 Dec 2020 09:35:15 -0700

Thanks, I'll check them out. 

On Sun, Dec 27, 2020 at 9:34 AM Marc Nieper-Wißkirchen <marc.nieper+gnu@gmail.com> wrote:
The canonical way to do this is to add a git submodule containing Gnulib.

Bootstrapping the whole thing is then done with the bootstrap script
provided by Gnulib.

You can check, say, GNU hello ([1]), to see how it is done. GNU Bison
([2]) or GNU tar ([3]) are also good examples.

-- Marc

[1] https://git.savannah.gnu.org/cgit/hello.git/tree/
[2] https://git.savannah.gnu.org/cgit/bison.git/tree/
[3] https://git.savannah.gnu.org/cgit/tar.git/tree/

Am So., 27. Dez. 2020 um 17:26 Uhr schrieb Daniel Schwen <lists@schwen.de>:
>
> The https://www.gnu.org/software/gnulib/ homepage states:
>
> "Gnulib takes a different approach. Its components are intended to be shared at the source level, rather than being a library that gets built, installed, and linked against. Thus, there is no distribution tarball; the idea is to copy files from Gnulib into your own source tree."
>
> On Sun, Dec 27, 2020 at 9:25 AM Marc Nieper-Wißkirchen <marc.nieper+gnu@gmail.com> wrote:
>>
>> 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
>> >>> >> >

reply via email to

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