|
| From: | Daniel Schwen |
| Subject: | Re: LibJIT / Lightning interoperability issue |
| Date: | Tue, 29 Dec 2020 10:37:12 -0700 |
It's true that adding Gnulib just for one m4 file looks like overkill,
but the goal should be to make more use of Gnulib in the future.
Everything that is implemented in Gnulib
(https://www.gnu.org/software/gnulib/MODULES.html) shouldn't be
doubled in GNU lightning.
It has to start somewhere, though, and I think that using the
visibility macros is a good start because it is not very intrusive.
Later, more of the source and the build system can be streamlined
using Gnulib according to GNU project's best practices.
Marc
PS Do you have a browsable source tree of your experiment with
Lightning+Gnulib, which currently doesn't work?
Am Mo., 28. Dez. 2020 um 18:30 Uhr schrieb Daniel Schwen <lists@schwen.de>:
>
> 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
>>> >>> >> >>> >> >
| [Prev in Thread] | Current Thread | [Next in Thread] |