[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: RE: Compiling Lua for uClinux create larger file than expected
- From: "Jay Carlson" <nop@...>
- Date: Tue, 19 Oct 2004 23:48:43 -0400
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
libm.
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?
Jay