Bug 249475 – gcj-dbtool -p reports a database which isn't the default

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Andrew John Hughes 2008-12-01 12:44:41 UTC]

gcj uses a database to map jar files to native libraries.  gcj-dbtool -p reports the default database which gcj uses by default.  On Gentoo with gcc 4.3.* it reports:

# gcj-dbtool -p
/usr/lib/../lib64/gcj-4.3.3-9/classmap.db

but strace shows that this isn't the database used when running gij without the -Dgnu.gcj.precompiled.db.path option.  Below is a diff between an strace without the path option and an strace with the output of gcj-dbtool -p passed as the argument to -Dgnu.gcj.precompiled.db.path:

- open("/usr/share/java/classmap.gcjdb", O_RDONLY) = -1 ENOENT (No such file or directory)
- open("/usr/share/locale/locale.alias", O_RDONLY) = 4
- open("/usr/share/locale/en_GB.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
- open("/usr/share/locale/en_GB.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
- open("/usr/share/locale/en_GB/LC_MESSAGES/libc.mo", O_RDONLY) = 4
- open("/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
- open("/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
- open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
- statfs("/selinux", 0x7fff451155f0) = -1 ENOENT (No such file or directory)
- open("/proc/mounts", O_RDONLY)    = 4
- open("/tmp/ffir42O08", O_RDWR|O_CREAT|O_EXCL, 0600) = 4
- unlink("/tmp/ffir42O08")          = 0
+ open("/usr/lib64/gcj-4.3.3-9/classmap.db", O_RDONLY) = 4
+ stat("/usr/lib64/gcj-4.3.3-9/classmap.db", {st_mode=S_IFREG|0644, st_size=1441792, ...}) = 0
+ open("/usr/lib64/native_ecj-3.3.so", O_RDONLY) = 5
+ open("/etc/ld.so.cache", O_RDONLY) = 5
+ open("/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/libgcj_bc.so.1", O_RDONLY) = 5


Reproducible: Always

Steps to Reproduce:
1. Run ecj using ecj.jar and gij
2. Compilation will be slow as any native library mapping in the gcj database is not used.
3.

Actual Results:  
Use of non-existent /usr/share/java/classmap.gcjdb and slow interpreted gij runs.

Expected Results:  
Use of default database and native code use by gij.

[Comment 1 Andrew John Hughes 2008-12-01 15:12:36 UTC]

This problem doesn't appear to be with the gcj build.  It's due to cruft in gcj-jdk.

[Comment 2 Andrew John Hughes 2008-12-01 15:19:26 UTC]

Fixed by gcj-jdk-4.3-r4 in java-overlay.

[Comment 3 Mark Loeser (RETIRED) 2008-12-01 16:24:42 UTC]

(In reply to comment #2)
> Fixed by gcj-jdk-4.3-r4 in java-overlay.
> 

So, the versions of gcj-jdk in the tree aren't broken?