[uClibc]Re: [BusyBox] tar and getopt (again)

[Manuel Novoa III]

Erik,

> k.  Ckeck it in as is.  uClibc already has a getopt_long -- the main reason I
> was looking at it is that since so few busybox apps use it, I was hoping to
> save space by not using it.  It saves space on a static compile, since the
> getopt_long code wouldn't get linked in, and it saves a (admittedly tiny) bit
> of space on a dynamic build, since the ELF vector code to fixup the external
> symbol isn't needed.  Not that big a deal.  Just a thought.

This brings up an issue similar to the "long long" stuff that came up this
weekend wrt libgcc.a. { On that issue, I'm thinking now that "long long" support
in uClibc _should_ be a build-time option, and if it is included then pull the
support routines from libgcc.a and add them to the shared lib. }

It would be nice to have a kind of pseudo-linker which you could pass a list of
the symbols you programs needed and build a customized shared uClibc. 
Something like:

   ld -r -o myapp1.ldr myapp1_*.o
   ld -r -o myapp2.ldr myapp2_*.o
   nm -s myapp[12].ldr | grep " U " | build-custom-shared-uClibc -o mylib.so

I remember doing something similar a few years ago in awk in order to debug a
problem in ncurses.  I needed to see where to break up some of the source files
to eliminate a number of unnecessary symbols being pulled in.

I think something like this is a good candidate application for the uClibc/extra
dir.  What do you think?

Manuel