lua-users home
lua-l archive

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


Am 23.06.2014 16:32 schröbte Bernd Eggink:
On 23.06.2014 12:22, Bernd Eggink wrote:
When I tried to compile Lua-SDL2-2.0.3-1 on 64-bit Linux, I got:

-----
/usr/bin/ld: /usr/bin/liblua.a(lapi.o): relocation R_X86_64_32 against
`luaO_nilobject_' can not be used when making a shared object; recompile
with -fPIC
/usr/bin/liblua.a: could not read symbols: Bad value
-----

This went away after re-compiling Lua with -fPIC, but I'm not sure about
the consequences.

On Linux it is customary to let the Lua interpreter re-export the Lua API to extension modules. `make linux` will take care of this. The extension modules _don't_ link to `liblua.a` (or `liblua.so`), so the Lua library doesn't need to be position independent code (but it won't hurt if it is).


Argh, meanwhile I noticed some consequences... For eaxmple, require
"posix" leads to

/usr/bin/lua: error loading module 'posix_c' from file
'/usr/lib/posix_c.so':
         dynamic libraries not enabled; check your Lua installation

Since dynamic libraries are not available in ISO C you need a preprocessor macro when compiling Lua: `LUA_USE_DLOPEN`. Again, the default Makefile should take care of this when invoked via `make linux`.


And 'luarocks help' outputs:

lua: /usr/share/lua/5.2/luarocks/loader.lua:12: attempt to call global
'module' (a nil value).

Older versions of LuaRocks need `LUA_COMPAT_MODULE` defined when building Lua 5.2 (`make linux` should do the trick). Either update LuaRocks, or compile Lua with `LUA_COMPAT_MODULE` defined.


So I re-re-compiled Lua without -fPIC, and my Lua-SDL2 problem persists.

- Bernd


Philipp