>>>>> "David" == David Daney <[EMAIL PROTECTED]> writes:
David> Perhaps the crazy person that only needs 2MB worth of the files from David> said static library when the corresponding shared library is David> 8MB. Especially if this lunatic is trying to make the program, OS David> kernel etc fit in an 8MB flash memory device. In general I think this thread is merging several issues that, while related, also require separate consideration: * Build times are too slow * Many programs that one might run on a Linux distro don't require all of libgcj.so; therefore it is too big * In some environments (including, surprisingly to me, Linux) it is convenient to ship a statically-linked-to-libgcj app * The humongosity of libgcj crushes embedded boxes In particular I think build times should ideally be addressed as a separate issue from deployment approaches, as the latter represent real user requirements, whereas the former can be turned into a collection of ad hoc hacks if need be. 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 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 would probably have to tend to this to prevent it breaking; I'd be reluctant to accept it as "fully supported" simply because I know I would never be building that way. (There is obviously some limit to how far this program could be carried; and at the extrema of customizability we would either need a radically different approach, or you would just have to accept that you need local changes.) FWIW, as far as splitting goes, I think it isn't just AWT/Swing, though those are the big ones. RMI and java.sql could probably be meaningfully broken off into separate libraries as well. It isn't clear how fine we should grind this. One actual conflict I foresee is that, as we compile more of the core library with -findirect-dispatch, it will get harder to use static linking sensibly. This is still a ways away, as the CNI problem has not yet been solved; and in any case exactly where the BC-ification will stop is still unknown. But, we have already started this and I think more will be showing up in the near future. Perhaps this can be solved by letting folks optionally compile libgcj with the C++ ABI. -whole-archive also "solves" this, though it eliminates the useful ability of static linking to drop the bits you aren't using (I think this is irreconcilable with how BC works). Our thinking has been that we would solve a lot of gcj problems with the BC ABI. And, in particular, once it is solid and complete, we would make it the default and then feel free to break C++ ABI compatibility even in minor releases; the idea being that this would be a way around the fact that GCC's release schedule is too slow for libgcj. I'm not sure what Plan B would be. Maybe separate libgcj releases somehow. Tom
