 |
lua-l archive |
|
|
||
|
On Tuesday, April 1, 2003, at 07:43 PM, Luiz Henrique de Figueiredo wrote:
Got a compile problem on Mac OS X:gcc -o ../../bin/luac -Wl,-E luac.o print.o lopcodes.o -L../../lib -llua -llualib -lm -ldl ld: unknown flag: -Econfig says: # Write here any options you may need for your C linker.# Support for dynamic loading in Linux with gcc needs -Wl,-E. If you are not # using gcc or do not want support for dynamic loading, leave MYLDFLAGS empty.# MYLDFLAGS= -Wl,-E So, just comment the line above. We left this as the default so that compilation under Linux would work cleanly.
(The following is specific to systems using SVR4 ELF shared libraries; I'm too lazy to pull up a Terminal window to figure out the right thing on OS X or AIX or etc.)
What -E means is that all symbols in the main program are exposed to dynamically loaded objects. Since in the default build, all of lua (liblua etc) is linked directly into the main program, this is necessary for loaded objects to do anything. It does mean that the internals of bin/lua are exposed to loaded objects.
However, best practice in this situation is to place liblua into its own shared library, and have loaded objects pick up symbols from there. That way there's a barrier between the application-specific main program and loaded objects. (If you want to get really picky, you should actually link the loaded objects against the shared liblua so that their dependency is marked.)
Some platforms may not allow loaded objects to reference symbols in the main program at all; I think AIX is or was such a platform.
Given that lua-5.0 doesn't have the complicated goo to build and install a shared library version of liblua by default, I think the current build process is about the best you can do. But I would like to advise people reusing Lua against blindly using ld -E in their new applications.
Jay