This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Patch: Remove fastjar
Mark Wielaard wrote:
On Thu, 2006-03-30 at 18:29 -0500, Andrew Pinski wrote:
Perhaps gcc/doc/install.texi should have something added to reflect the
new requirements for building.
I still say there is a misunderstanding going on because not all
people will already have a jar program installed (in fact I don't
one installed on my work GNU/Linux box). Making a new requirment
to compile libgcj will make GCC people think twice about compiling
GCC.
It is going to be a bit of extra pain for users to compile libgcj if
this is removed from the tree. Would it be possible to use the minizip
implementation from the included zlib to create the jar/zip file? That
way we don't introduce an extra dependency on the user. Or try to detect
a working zip binary on the users system? At least a zip utility is more
likely to be available then a jar utility.
Ideally, I'd like to get rid of fastjar. It should be replaced by a
wrapper on top of java.util.zip and java.util.jar. I assume this is
what Sun does. Is there any reason to not do that?
For bootstrapping, we can use zip/unzip if an installed jar isn't
available. Though I'm not sure why we need either.
One factor is that jar/fastjar is a host application, while we build
libgcj for target. I don't think that's a problem: Part of the
bootstrap process when building a cross-compiler could reasonably
be to build host versions of the libraries. We used to do this
for libiberty; I don't know what we currently do. Presumably
this is not a problem at this point - gcjx would obviously need C++
host libraries.
--
--Per Bothner
per@bothner.com http://per.bothner.com/