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: Mon, 28 Dec 2020 10:30:11 -0700

Anyhow, I've sunk quite a bit of time into this and I'm wondering if such a major change of the build system is worth it. I'm just adding a single short m4 file to get the -fhidden detection working. The majority of the changes in the patch are to the lightning source. Seems overkill to me to add gnulib as a submodule at this point. 
If in the future more features of gnulib will get used, then this effort would make a lot more sense.

On Mon, Dec 28, 2020 at 8:11 AM Daniel Schwen <lists@schwen.de> wrote:
Yeah. I wonder if I set it up correctly. In two of the gnu projects you linked to there is a local.mk file in the lib dir and the Makefile.am is generated by bootstrap. Only tar has a checked in Makefile.am
I cannot figure out the difference in configuration. 

On Mon, Dec 28, 2020, 4:20 AM Marc Nieper-Wißkirchen <marc.nieper+gnu@gmail.com> wrote:
It does overwrite GNU lightning's Makefile.am?

Am So., 27. Dez. 2020 um 18:32 Uhr schrieb Daniel Schwen <lists@schwen.de>:
>
> Ok, so far so good. Added gnulib as a submodule, copied bootstrap and bootstrap.conf to project root, added
>
> gnulib_modules="
>   lib-symbol-visibility
> "
>
> in bootstrap.conf and tested by running `./bootstrap --force`
>
> However, this now overwrites Makefile.am where I added the -DBUILDING_LIBLIGHTNING (per gnulib docs!)
> I cannot find where this option should go now.
> Any ideas?
> Daniel
>
> On Sun, Dec 27, 2020 at 9:35 AM Daniel Schwen <lists@schwen.de> wrote:
>>
>> 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]