[Bug java/24698] New: [4.1 regression] Apparent problem getting non-.class files out of jars

["bero at arklinux dot org" <gcc-bugzilla at gcc dot gnu dot org>]

Sorry for the vague description and huge test case - I don't speak Java beyond
the "it looks a lot like C++" level.

Trying to use a gcj 4.1 SVN rev 106562-compiled ecj (built using the workaround
from bug 24441) results in a SIGABRT when trying to translate any .java file
(even a simple helloworld.java).

strace-ing the output indicates it can't locate the compiler messages, which
are in messages.properties, which is definitely included in the .jar and the
.jar is in the classpath. Looks like gcj/gij look for a messages.class file
instead.
Relevant parts of strace output:
* open("/usr/lib/libeclipse-ecj.so", O_RDONLY) = 3
<--- It finds the precompiled version [the problem doesn't go away if I delete
that and use the .jar only]
* stat64("/usr/share/java/eclipse-ecj.jar", {st_mode=S_IFREG|0644,
st_size=905576, ...}) = 0
* open("/usr/share/java/eclipse-ecj.jar", O_RDONLY|O_LARGEFILE) = 9
<--- It finds and reads the jar file nevertheless
* open("/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages_en_US.la",
O_RDONLY) = -1 ENOENT (No such file or directory)
*
open("/usr/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages_en_US.la",
O_RDONLY) = -1 ENOENT (No such file or directory)
* open("lib-org-eclipse-jdt-internal-compiler-batch-messages_en_US.la",
O_RDONLY) = -1 ENOENT (No such file or directory)
* access("/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages_en_US.so",
R_OK) = -1 ENOENT (No such file or directory)
*
access("/usr/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages_en_US.so",
R_OK) = -1 ENOENT (No such file or directory)
* open("/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages_en_US.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
*
open("/usr/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages_en_US.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
*
access("/home/arklinux/./org/eclipse/jdt/internal/compiler/batch/messages_en.properties",
F_OK) = -1 ENOENT (No such file or directory)
* open("/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages.la",
O_RDONLY) = -1 ENOENT (No such file or directory)
* open("/usr/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages.la",
O_RDONLY) = -1 ENOENT (No such file or directory)
* open("lib-org-eclipse-jdt-internal-compiler-batch-messages.la", O_RDONLY) =
-1 ENOENT (No such file or directory)
* access("/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages.so", R_OK)
= -1 ENOENT (No such file or directory)
* access("/usr/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages.so",
R_OK) = -1 ENOENT (No such file or directory)
* open("/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
* open("/usr/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
access("/home/arklinux/./org/eclipse/jdt/internal/compiler/batch/messages.class",
F_OK) = -1 ENOENT (No such file or directory)
<--- It looks for org.eclipse.jdt.internal.compiler.batch.messages* in various
places without finding anything, insisting it's supposed to be a .class when
it's in fact looking for messages.properties

[strace-ing the 4.0.x generated version confirms messages.properties is what
it's looking for].

$ jar tfv eclipse-ecj.jar |grep compiler/util/messages
  2764 Wed Jan 12 00:13:34 CET 2005
org/eclipse/jdt/internal/compiler/util/messages.properties


The same code (and build process) works nicely if gcj/gij 4.0.x is used.


-- 
           Summary: [4.1 regression] Apparent problem getting non-.class
                    files out of jars
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: java
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: bero at arklinux dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698