[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug classpath/32516] gjar may create "." directory into the root of the
From: |
thebohemian at gmx dot net |
Subject: |
[Bug classpath/32516] gjar may create "." directory into the root of the archive |
Date: |
10 Dec 2007 19:40:21 -0000 |
------- Comment #1 from thebohemian at gmx dot net 2007-12-10 19:40 -------
----
Hi guys,
today I tripped on some weird incompatibility between ecj (3.3.1 as
found in Debian Lenny) and gjar 0.95:
gjar creates jars which need zip version 2.0 to extract, while e.g.
fastjar creates files which are readable by version 1.0.
This is what 'file' says:
src1-fastjar.jar: Zip archive data, at least v1.0 to extract
src1-gjar.jar: Zip archive data, at least v2.0 to extract
The problem comes when you want to compile something with ecj and put
such a jar (the gjar-created one) in the classpath or bootclasspath.
It simply does not find the files!
ecj -cp ../src1-gjar.jar use/Test.java
----------
1. ERROR in use/Test.java (at line 3)
import base.Base;
^^^^
The import base cannot be resolved
----------
2. ERROR in use/Test.java (at line 9)
Base b = new Base("Test");
^^^^
Base cannot be resolved to a type
----------
3. ERROR in use/Test.java (at line 9)
Base b = new Base("Test");
^^^^
Base cannot be resolved to a type
----------
3 problems (3 errors)address@hidden:~/tmp/jartest/src2$
Looking at the jar's content reveals that a class is there:
gjar -tf src1-gjar.jar
META-INF/MANIFEST.MF
./base/Base.class
Who is the one to blame? Is ecj unable to process version 2.0 zip files
or does gjar create unsuitable files? Is this a known issue?
If you do not believe what you see have a look at the attached sources.
Create the two jars using the two shell scripts in src1 and then try to
compile the class in src2 using the shell scripts within it.
----
Andrew Haley found out:
Note that gjar adds "./" to the start of the path, and jar does not.
That's the bug: gjar needs to strip "./" from the start of the path.
----
I further investigated the problem and am convinced too that the problem
is in the gjar code. I ruled out the following other situations:
- classpath' zip code is broken and should handle ./ entries
transparently. This is not the case JDK does the same. I tested this by
using ecj with JDK and a gjar-created jar. You get the same error.
- classpath' zip code is broken and should remove ./ entries
automatically when creating zip files. This is not the case and I found
this out by running gjar on JDK. Those files contains ./ prefixes, too.
later I added:
--
thebohemian at gmx dot net changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |thebohemian at gmx dot net
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2007-12-10 19:40:21
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32516
- [Bug classpath/32516] gjar may create "." directory into the root of the archive,
thebohemian at gmx dot net <=