Re: [ANNOUNCE] Lua 5.0 (pre-release) now available

[Jay Carlson <nop@...>]

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: -E
>
> config 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