Hello,
it is possible to build a shared library, but you shall assume, that the ones
who build cgit from source code, build also liblua from source code. And the
result is static liblua.a .
On 10/23/2016 05:55 PM, John Keeping wrote:
I assume it's possible to build a shared library; I get both shared and
static installed by my package manager.
It looks like there is some performance concern about using a shared
libary for Lua[1], but I doubt performance is critical for most uses
with CGit so I would recommend building and linking to the Lua shared
library if possible.
If you need to link to the static library, I think it will be safer to
use:
-rdynamic -fvisibility=hidden
but that will still expose all of the symbols from libgit.a, which was
not designed to be used as a library by third-party code and thus does
not prefix its symbols, so you still have to be wary of symbol
collisions with other libraries.
[1] http://article.gmane.org/gmane.comp.lang.lua.general/18519
On Fri, Oct 21, 2016 at 09:54:23AM +0200, Дилян Палаузов wrote:
liblua is linked statically. This is what you get, when you compile
Lua from source (no liblua.so).
On 10/16/2016 01:55 PM, John Keeping wrote:
On Sun, Oct 16, 2016 at 07:30:08AM +0200, Дилян Палаузов wrote:
on my system I wanted to link cgit with lua, so that lua can load the
(lua)crypto.so module. For this to work the symbol lua_gettop has to
be exported by cgit. I managed this by passing "-Wl,-E" to the
linker, when compiling cgit.
How are you linking to liblua? I thought we normally linked that
dynamically so the symbol should be exported from the shared library
even if the cgit binary does not export symbols.
_______________________________________________
CGit mailing list
[email protected]
http://lists.zx2c4.com/mailman/listinfo/cgit
