lua-users home
lua-l archive

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

Mike Crowe writes:

> MCrowe@MCrowe lua $ l lib
> total 128
> -rw-rw-rw-    1 MCrowe   mkpasswd   130638 Oct 19 21:59 liblua.a
> -rw-rw-rw-    1 MCrowe   mkpasswd    92316 Oct 19 21:59 liblualib.a
> MCrowe@MCrowe lua $ l bin
> total 395
> -rw-rw-rw-    1 MCrowe   mkpasswd   403948 Oct 19 21:59 lua
> MCrowe@MCrowe lua $

"I don't see the problem." 

Oh, you mean that it's much bigger than you expected?  My guess is that it's
pulling in substantial parts of libc and libm.  That's not surprising, given
that one of Lua's informal missions is to use every part of ANSI libc and

I'm guessing your architecture doesn't have dynamic loading for shared
libraries.  FWIW, it's not that hard to write a dynamic loader; I did one
for mipsel-linux for PDAs a while ago.  Lemme know if you want hints.
Dynamic linking, OTOH, is No Fun.

....ohhh, you don't have an MMU.  Ugh.  Shared libraries are going to need
toolchain support if not source modifications.  I can get paid for that
level of work since it, as well, is No Fun.

(I believe my last message to the list included criticism on the basis of
fun, so I feel like I'm allowed to spam that word some more.)

For fun, try running these commands:

# Find the absolute path of a shared library
flib () { nios2-elf-gcc -print-file-name=lib$1.a ; }
# Partially link lua and lualib, resolving all internal references
nios2-elf-ld -r --whole-archive `flib lua` `flib lualib` -o /tmp/lua.o
# Get the actual linkable size of that
nios2-elf-size /tmp/lua.o
# Compare with libc:
nios2-elf-size --total `flib c` | tail -1
# Browse through the functions Lua is calling for in libc
nios2-elf-nm /tmp/lua.o | grep ' U ' | more

After that, you'll have to start hunting through linker maps to see how Lua
calling for sprintf drags in huge chunks of other libc stuff.  

In general, you get more geek points if you complain about bloat via the
size command rather than ls, which includes lots of other overhead which may
or may not affect execution size.

Did you already get rid of the libm dependencies?