Re: Patch: Remove fastjar

[Per Bothner <per@bothner.com>]

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/