Re: 4.5.2 doesn't build due to wrong jar-usage (gcj)

Re: 4.5.2 doesn't build due to wrong jar-usage (gcj)

[Andrew Haley]

On 12/31/2010 09:33 PM, Oliver Kullmann wrote:
> Hello,
>
> trying to build gcj with gcc version 4.5.2 I get the build error
>
> checking for i686-pc-linux-gnu-ar... ar
> checking for i686-pc-linux-gnu-ranlib... ranlib
> checking for i686-pc-linux-gnu-dlltool... dlltool
> checking for gawk... (cached) gawk
> checking for jar... jar
> checking for zip... no
> checking for unzip... /usr/bin/unzip
> Illegal option: @
> Usage: jar {ctxui}[vfm0Me] [jar-file] [manifest-file] [entry-point] [-C dir] files ...
> Options:
>      -c  create new archive
>      -t  list table of contents for archive
>      -x  extract named (or all) files from archive
>      -u  update existing archive
>      -v  generate verbose output on standard output
>      -f  specify archive file name
>      -m  include manifest information from specified manifest file
>      -e  specify application entry point for stand-alone application
>          bundled into an executable jar file
>      -0  store only; use no ZIP compression
>      -M  do not create a manifest file for the entries
>      -i  generate index information for the specified jar files
>      -C  change to the specified directory and include the following file
> If any file is a directory then it is processed recursively.
> The manifest file name, the archive file name and the entry point name are
> specified in the same order as the 'm', 'f' and 'e' flags.
>
> Example 1: to archive two class files into an archive called classes.jar:
>         jar cvf classes.jar Foo.class Bar.class
> Example 2: use an existing manifest file 'mymanifest' and archive all the
>             files in the foo/ directory into 'classes.jar':
>         jar cvfm classes.jar mymanifest -C foo/ .
>
> configure: error: cannot find neither zip nor jar, cannot continue
> make[2]: *** [configure-target-libjava] Error 1
> make[2]: Leaving directory `/compsci/saturn/staff/csoliver/OKplatform/ExternalSources/builds/Gcc/gcc-4.5.2_build'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/compsci/saturn/staff/csoliver/OKplatform/ExternalSources/builds/Gcc/gcc-4.5.2_build'
> make: *** [gcc] Error 1
> make: Leaving directory `/compsci/saturn/staff/csoliver/OKplatform/ExternalSources'
>
> jar exists (also unzip, but not zip), however it thinks it is wrongly used?
> The requirements page of gcc only says that "jar or zip" is needed, and nothing
> is said about version-numbers of jar?
>
> On the Internet I don't find something on this error (only really missing jar
> on windows machines).
>
> Apparently jar doesn't follow the usual Unix-tool standards, so you can't ask
> it (apparently) about its version or for help. Since I don't use jar, I don't
> know what to do here.

This should be autodetected.  The problem usually occurs when gcc has been
configured, and then something goes wrong, and then make is restarted.  The
usual cure is to blow away the libjava directory and start again.

Andrew.

Re: 4.5.2 doesn't build due to wrong jar-usage (gcj)

[Oliver Kullmann]

> >configure: error: cannot find neither zip nor jar, cannot continue
> >make[2]: *** [configure-target-libjava] Error 1
> >make[2]: Leaving directory 
> >`/compsci/saturn/staff/csoliver/OKplatform/ExternalSources/builds/Gcc/gcc-4.5.2_build'
> >make[1]: *** [all] Error 2
> >make[1]: Leaving directory 
> >`/compsci/saturn/staff/csoliver/OKplatform/ExternalSources/builds/Gcc/gcc-4.5.2_build'
> >make: *** [gcc] Error 1
> >make: Leaving directory 
> >`/compsci/saturn/staff/csoliver/OKplatform/ExternalSources'
> >
> >jar exists (also unzip, but not zip), however it thinks it is wrongly used?
> >The requirements page of gcc only says that "jar or zip" is needed, and 
> >nothing
> >is said about version-numbers of jar?
> >
> >Apparently jar doesn't follow the usual Unix-tool standards, so you can't 
> >ask
> >it (apparently) about its version or for help. Since I don't use jar, I 
> >don't
> >know what to do here.
> 
> This should be autodetected.  The problem usually occurs when gcc has been
> configured, and then something goes wrong, and then make is restarted.  The
> usual cure is to blow away the libjava directory and start again.
>

I don't understand: Nothing was restarted, but this is just the complete build?

Or is it related to me doing (repairing) something in the build directories?
That would be rather difficult, since this is part of our package, which
needs to be installed automatically by the user.

Oliver

Re: 4.5.2 doesn't build due to wrong jar-usage (gcj)

[Andrew Haley]

On 01/07/2011 08:10 PM, Oliver Kullmann wrote:
 >>> configure: error: cannot find neither zip nor jar, cannot continue
 >>> make[2]: *** [configure-target-libjava] Error 1
 >>> make[2]: Leaving directory
 >>> `/compsci/saturn/staff/csoliver/OKplatform/ExternalSources/builds/Gcc/gcc-4.5.2_build'
 >>> make[1]: *** [all] Error 2
 >>> make[1]: Leaving directory
 >>> `/compsci/saturn/staff/csoliver/OKplatform/ExternalSources/builds/Gcc/gcc-4.5.2_build'
 >>> make: *** [gcc] Error 1
 >>> make: Leaving directory
 >>> `/compsci/saturn/staff/csoliver/OKplatform/ExternalSources'
 >>>
 >>> jar exists (also unzip, but not zip), however it thinks it is wrongly used?
 >>> The requirements page of gcc only says that "jar or zip" is needed, and
 >>> nothing is said about version-numbers of jar?
 >>>
 >>> Apparently jar doesn't follow the usual Unix-tool standards, so you can't
 >>> ask
 >>> it (apparently) about its version or for help. Since I don't use jar, I
 >>> don't
 >>> know what to do here.
 >>
 >> This should be autodetected.  The problem usually occurs when gcc has been
 >> configured, and then something goes wrong, and then make is restarted.  The
 >> usual cure is to blow away the libjava directory and start again.
 >
 > I don't understand: Nothing was restarted, but this is just the complete build?
 >
 > Or is it related to me doing (repairing) something in the build directories?
 > That would be rather difficult, since this is part of our package, which
 > needs to be installed automatically by the user.

The only time I have ever seen this happen is when the build is stopped
after configure, something is changed, and then the build restarted.  If
this did not happen, then we have a new bug.

In that case, to debug this we'll need to know exactly how to duplicate
the problem, in precise detail.

Andrew.