RE: Compiling Lua for uClinux create larger file than expected

["Jay Carlson" <nop@...>]

Mike Crowe writes: 

> Excellent info!  Here's some points:
> MCrowe@MCrowe lib $ nios2-elf-size /tmp/lua.o
>    text    data     bss     dec     hex filename
>  111152    1261       0  112413   1b71d /tmp/lua.o
> MCrowe@MCrowe lib $ nios2-elf-size --total `flib c` | tail -1
>  153213    3066     748  157027   26563 (TOTALS)
> 
> Therefore (I think), most of the uClibc is getting pulled in, right?

I'm not sure.  A good portion of it will be.  Can you run "size" on your lua
executable?  I'd like to compare its output to that of ls -l.

BTW, it's not a good idea to strip .a files.  However, you can strip
executables, which will provide strictly better results than just stripping
the upstream files.

mipsel-linux has a bunch of useless sections in ELF executables even after
running strip, so we had to make a "stripall" script that passed in more
aggressive options.  I doubt that's true of the format used on uclinux.

> uClinux does not have an MMU, so I'm stuck with static, I guess.
Currently, we
> only offer C/C++ as languages, and I wanted to offer a higher level
language, and
> lua appears to be it.

Just about any higher level language is going to need substantial parts of
libc.  When you statically link a C program, the linker can figure out what
will never be used.  When you build a language interpreter, it has to carry
around say, fopen, because a script might want to use it.

I thought there were a couple of shared library strategies on uclinux,
although they were quite architecture-specific.  IMO shared libraries are
important to have on small hardware as they allow you to use the Unix
philosophy of smaller tools hooked together.  Without shared libraries, you
tend to end up building "all-in-one" executables like busybox. 

> I'm hoping that Lua + compiled lua-code will be better than porting a JVM
to
> language.  Thoughts?

Oh, almost certainly, for space usage.

Jay