[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: 5.1 beta problem linking luac against .so
- From: Mike Pall <mikelu-0511@...>
- Date: Wed, 23 Nov 2005 20:48:14 +0100
Hi,
John Belmonte wrote:
> I can link lua interpreter against the .so form of the Lua library,
Ouch -- I knew it. That's for the Debian package, right?
PLEASE, PLEASE DON'T DO THIS!
It has been discussed a few times on the list. It's a deadly
sin to link the Lua interpreter against a shared library compiled
with -fpic on x86 platforms. You'll loose anywhere between 10-20%
of speed and this is clearly unacceptable.
The main loop of the interpreter (luaV_execute) is very sensitive
to the number of available registers. Compiling a shared library
with -fpic on x86 makes 1 out of 6 registers unavailable and
forces the compiler to produce really bad code.
The best idea is _not_ to compile a shared library at all. Just
link lua (the interpreter) statically. There is no downside to
it -- it's very small after all. And executables _are_ shared in
memory, too.
Any application incorporating Lua is better served by linking it
statically. It needs to be modified in many cases. Many apps are
very version specific, since the ABI changes on minor Lua
versions, too.
And if you really, really insist on making a shared library
available then by all means compile it twice and link the Lua
interpreter statically against the version _not_ compiled
with -fpic. That's exactly what is usually done with Perl
and Python (for the very same reason). Thank you!
> but when linking luac the following undefined's come up:
> luac.c:(.text+0x1f2): undefined reference to `luaF_newproto'
>[...]
These are internal symbols after all. Not that luac needs to be
fast, but it's a lot easier to link it statically.
[
A better solution is to provide introspection capabilities in
the Lua core and then make luac a simple lua script. There is
such a script right now, but it has limited features.
FYI: LuaJIT has these introspection capabilities added and they
need less than 1.5K of code space. IMHO it would be entirely
reasonable to add this to the standard Lua core. Guess it's a bit
late now to discuss this for 5.1.0 ...
]
> If I remove the "__attribute__((visibility("hidden")))" from LUAI_FUNC
> and LUAI_DATA in luaconf.h then the link is OK.
This is a bad idea because then you'll force the compiler to
generate even worse code for shared libraries. The attribute was
introduced to avoid this (and to avoid pollution of the exported
symbol space).
Ok, you could remove the attribute only for the required symbols.
But your best bet is to link luac statically and avoid all the
hassle. We are talking about 150K -- this is 1/1.000.000 of the
average size harddisk sold nowadays.
[NB: This discussion is about desktop or server environments, not
about embedded environments.]
Bye,
Mike