Re: statically linked executable size

[Per Bothner <per at bothner dot com>]

Marco Trudel wrote:
> Per Bothner wrote:
> > Does Elf have a mechanism to specify that this object/library requires
> > some other library?  If so, then we can use that mechanism.
>
> If I understand you right, then you suggest what actually happens right 
> now and is the source of the problem: java is that heavily 
> interconnected, we end up with executables which include a big part of 
> the API.

What happens right now is that we're searching a single huge library,
which is searched automatically only because the gcj program add a
linker command to search that library.

Tom's message was about splitting that library into multiple smaller
libraries.  This can help *dynamically* linked executables, which is
the primary focus of Java on the desktop or the server.  (In this case
we don't care about executable size so much. but we care about startup
time and resident memory size.)  Splitting the library won't help
statically linked executables, which is also a concern, but we have a
different set of priorities.  (Thus the subject line may be misleading.)

A problem with splitting up libraries is that linker command lines in
Makefiles etc may have to be changed to explicitly mention the new
libraries.  Alternatively, we could have gcj and related drivers
automatically search the new libraries.  But we want to link in the new
libraries *only* if they're actually referenced from the application -
otherwise we're not gaining anything.

My point is that asking people to explicitly specify -l flags is
losing.  Even having a "driver" like gcc/g++/gcj explicitly specify
-l flags is broken.  This should be handled by the compiler putting in
the appropriate requirement in the object file: If the compiler emits
a reference to a label Foo in library bar then at the same time it
should store in the object file that this object file requires library
bar.  Then the linker knows it needs to search library bar, without
this having to be explicitly specified.

Alternatively, the linker could auto-search all libraries on the -L
library search path.  For performance you'd want to pre-built
symbol->library map database/file, at least for system libraries.
This has the advantage that you don't need to change the compilers;
just the linker.  (Of I'm talking about the ld command - not the
dynamic linker.)
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/