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.

> overhead of, say, BC-compiling AWT and putting it in a separate .so
> doesn't seem unreasonable, based on our experiences with BC compiling
> large apps.  (Even this situation has its losers, for instance CNI
> users accessing AWT, like the xlib peers.  It looks impossible to
> please everybody 100%.)
>
> This split would help Windows users, too, I think, as at least AWT and
> Swing are fairly useless on that platform (no native peers; you can
> run the Gtk peers but that is weird).
>
> For embedded platforms, I would not mind seeing patches to allow
> completely disabling parts of the build based on configure switches.
> E.g., a switch to drop AWT entirely would be fine by me.  Someone

Shouldnt the linker do that already at runtime? Ok you pay the cost
of building it when gcc is built and storing the libraries on disk,
but in the final executable all should be only linked in when actually
referenced.

I know it can take quite some effort to make libraries really static
linking friendly so that libraries dont pull in other code intentionally
(take a look at nm of a a static glibc program to see how it should be not
done), but I would hope at least that the GUI and non GUI parts 
of libgcj are clearly separated.

-Andi

Reply via email to