Re: LibJIT / Lightning interoperability issue

[Marc Nieper-Wißkirchen]

Hi,

as I said earlier I think it makes a lot of sense to include Gnulib into GNU lightning to enable sharing compatibility code with other GNU projects.

While Gnulib itself is a large project, simply including it doesn't add any build dependency nor does it increase the code size.

I am going to send out a patch in a moment, which adds Gnulib to GNU lightning. So far, the only difference is that

$ ./bootstrap

will generate ./configure after checking out the Git sources.

In the next step, one can use Gnulib's visibility.m4 for the original goal of this thread.  While Gnulib may look like overkill just for this simple m4 macro, it paves the way for further portability additions to GNU lightning.  Moreover, visibility.m4 won't have to be maintained twice if included through Gnulib.

Thanks,

Marc

Am Mi., 3. März 2021 um 21:06 Uhr schrieb Paulo César Pereira de Andrade <paulo.cesar.pereira.de.andrade@gmail.com>:

Em sáb., 26 de dez. de 2020 às 22:58, Daniel Schwen <lists@schwen.de> escreveu:
>
> Hello list,

  Hi,

> 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 wonder if somebody experimented building lightning with a compiler
other than gcc or clang. Also, I do not know how symbol visibility would
work on windows (cygwin/mingwin) when built with gcc or gcc based
compiler. That would be a good reason to have it a bit more complicated,
and have the preprocessor define to know if building lightning.

> 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.

  The easiest approach would be something like:

#if (__GNUC__ >= 4)
#  define PUBLIC        __attribute__ ((visibility("default")))
#  define HIDDEN        __attribute__ ((visibility("hidden")))
#else
#  define PUBLIC        /**/
#  define HIDDEN        /**/
#endif

then, likely just tag prototypes with PUBLIC and leave everything else
with default visibility, that would be passed based on some configure.ac
check. Could add a specific file, or just mostly/fully copy&paste the text
in m4/visibility.m4

  As a note, looking at Xorg sources, it uses a macro checking for
__GNUC__ >= 4, and not defined __CYGWIN__ or __MINGWIN__.
It also adds the proper preprocessor for suncc, and inlines a simpler
version of gl_VISIBILITY.

  Compiling with default hidden visibility is a very good optimization,
as it allows the compiler to generate better or more optimized code,
and more inlining of common patterns, what lightning has a lot; where
it was added mostly to make the code easier to read.

> Cheers,
> Daniel

Thanks,
Paulo