On Sat, 2005-05-07 at 13:58, Andi Kleen wrote: > Tom Tromey <[EMAIL PROTECTED]> writes: > > > > Splitting up libgcj.so probably makes sense even for the Linux distro > > case (the one I am most concerned with at the moment), just so that > > apps that don't use AWT or Swing don't really pay for it. The > > Hmm? Unless you initialize AWT/swing in all programs that code > should never be paged in for non GUI programs. Ok in theory > if you use a random build order then a lot of pages could > contain GUI and non GUI code together, but that is probably > unlikely. > > The only reason to split it out would be to allow a libgcj > installation that is not dependent on the X11 libraries on the > RPM/dpkg/etc. level for small setups, but I am not sure how useful > that is anymore for most distributions. > > And perhaps to make the linking steps in the gcc build a bit > faster, but just for that it seems like a lot of work.
Don't forget that the dynamic linker still has to do some relocation at load time. Not all platforms support pre-linking to mitigate this, and even those that do don't necessarily have it done on all shared libraries. The size of libgcj is such that it has non-trivial amounts of start up linking to do. If you then add in redundant X libraries that it pulls in for apps that don't need the graphics the overall effect can be significant. R.
