This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
For instance, we could split libgcj into several smaller libraries and use the not-yet-written versioned directory scheme to make them invisible to the end user (a request for java.awt.foo would load the part of libgcj in the magic install directory).
But, this messes up two sets of users: people who want static linking
and people who want old-style C++ ABI linking and who use classes that
have been split off.
I'm not averse to something more ad hoc, like '--without-xml',I'd like to see a more general solution for building custom libgcj's for static application deployment. Putting in a configure switch for everything might just end up being a maintenance burden for something that isn't particularly useful. For a regular shared library deployment of libgcj, the idea is to replace the JVMs functionality, thus we always want to include everything.
'--without-awt', etc.
There's still the somewhat open question of whether "one big libgcj.so" is good for anybody really. Not all java apps use all this stuff, having it in separate libraries may save us something. I haven't done the measurements though, and it could go either way.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |