From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7 Description of problem: The x86-64 gij is a 64-bit application. All .jar files are also built as 64-bit .so files, and we maintain a /usr/lib64/classmap.db file. However, at runtime, strace tells us that libgcj is trying to read /usr/lib/classmap.db, so no native versions of the .jar files are every used. Running gij with -Dgnu.gcj.precompiled.db.path=/usr/lib64/gcj-4.1.0/classmap.db shows that .jar.so file execution works, so we just need to either a) build all java stuff as 32-bit only, or b) make sure libgcj is pointed at /usr/lib64/gcj-4.1.0/classmap.db Version-Release number of selected component (if applicable): libgcj-4.1.0-0.10 How reproducible: Always Steps to Reproduce: 1.Run any java program 2.Use lsof to see what files it has open. You won't see any .jar.so files. 3. Additional info:
This appears to be the same as https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174616
*** Bug 174616 has been marked as a duplicate of this bug. ***
The libgcj side should be fixed in gcc-4.1.0-0.14, please test it out. Now, /usr/bin/rebuild-gcj-db needs to be fixed to regenerate all multilib databases. I'd say just iterating over /usr/lib*/`dirname $(gcj-dbtool -p /)` would be sufficient.
I just did a fresh x86-64 test2 install and yum update. This appears to be fixed. I'm going to close it. Thanks!