Size problem

[Tom Tromey]

>>>>> "Jeff" == Jeff Sturm <jsturm@one-point.com> writes:

Jeff> $ size liboracle.so.8.1.7
Jeff>    text    data     bss     dec     hex filename
Jeff> 4491364 1017388    2224 5510976  541740 liboracle.so

Jeff> We could link this statically into each executable.  Like Adam
Jeff> says, disk space is cheap.

Also, if the library is used by many executables, it will be shared.
This must be an important memory savings, at least when you're
pressing your machine's limits.

Jeff> An interesting data point for GNU/Linux users is that libgcj.so
Jeff> is likely to be provided by the OS distributor eventually, as is
Jeff> done for libc.so and libstdc++.so now.

We're already there.  libgcj is in Red Hat Linux, Debian, etc.  Right
now, I think, it isn't part of the core OS distribution.  And I'm
pretty sure the vendors don't pay attention to libgcj issues the same
way they do with more critical libraries.  I expect that to change
once we have some killer apps that ship on top of libgcj.  Suddenly
we'll have to start paying attention to binary compatibility, etc,
like the g++ developers

Jeff> That won't be very useful until libgcj is more stable than it is
Jeff> today, and probably not before the binary compatibility patches
Jeff> are complete.

That work seems pretty important to me.

Tom