On Sat, Feb 27, 2010 at 3:34 PM, steve donovan <firstname.lastname@example.org>
Fair enough, but how have we managed to do without it then? Is it
similar to that fixed base address issue with Windows DLLs which bites
Lua modules compiled without PIC *will* work, with two caveats: increased memory consumption, because each Lua process may end up with its own copy of the module code, and the compiler may optimize intra-module access to the global symbols of the module and resolve them directly instead of through the global offset table, preventing the overriding of these global symbols by other shared objects.
I do not see either of these as a big deal for Lua modules. Most likely the only global symbol in your module is the luaopen_<modulename> function, and you will not have any calls to it inside your module, so you are free to override this function in another shared object. And Lua modules are small (the biggest one in my system is LPEG, at ~75Kb).
It is a trade-off. LuaRocks always compiles Linux modules from source, so anyone who wants LuaRocks to always use fPIC is welcome to add
variables.CFLAGS = "-O2 -fPIC"
Thankfully the point will be moot once we all migrate away from x86.