[Bug libgcj/27265] New: ClassNotFoundException: gnu.java.awt.peer.gtk.GtkToolkit
On x86_64, the following test produces an error:
public class TestAWT {
public static void main (String args[]) {
new java.awt.Frame();
}
}
Exception in thread "main" java.awt.AWTError: Cannot load AWT toolkit:
gnu.java.awt.peer.gtk.GtkToolkit
at java.awt.Toolkit.getDefaultToolkit (libgcj.so.7)
at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment (libgcj.so.7)
at java.awt.Window. (libgcj.so.7)
at java.awt.Frame. (libgcj.so.7)
at java.awt.Frame. (libgcj.so.7)
at TestAWT.main (TestAWT.java:3)
Caused by: java.lang.ClassNotFoundException: gnu.java.awt.peer.gtk.GtkToolkit
at java.lang.Class.forName (libgcj.so.7)
at java.awt.Toolkit.getDefaultToolkit (libgcj.so.7)
...5 more
strace shows that it is not opening the 64-bit lib. It is opening the 32-bit
lib, however!
$ strace -f -e trace=file gij41 TestAWT 2>&1|grep -i gtk
[pid 20278] open("/lib/lib-gnu-java-awt-peer-gtk-GtkToolkit.la", O_RDONLY) = -1
ENOENT (No such file or directory)
[pid 20278] open("/usr/lib/lib-gnu-java-awt-peer-gtk-GtkToolkit.la", O_RDONLY)
= -1 ENOENT (No such file or directory)
[pid 20278] open("lib-gnu-java-awt-peer-gtk-GtkToolkit.la", O_RDONLY) = -1
ENOENT (No such file or directory)
[pid 20278] access("/lib/lib-gnu-java-awt-peer-gtk-GtkToolkit.so", R_OK) = -1
ENOENT (No such file or directory)
[pid 20278] access("/usr/lib/lib-gnu-java-awt-peer-gtk-GtkToolkit.so", R_OK) =
-1 ENOENT (No such file or directory)
[pid 20278] open("/usr/lib64/../lib64/lib-gnu-java-awt-peer-gtk-GtkToolkit.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 20278] open("/usr/lib64/../lib64/lib-gnu-java-awt-peer-gtk-GtkToolkit.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 20278] open("/lib64/tls/lib-gnu-java-awt-peer-gtk-GtkToolkit.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 20278] open("/lib64/lib-gnu-java-awt-peer-gtk-GtkToolkit.so", O_RDONLY) =
-1 ENOENT (No such file or directory)
[pid 20278] open("/usr/lib64/lib-gnu-java-awt-peer-gtk-GtkToolkit.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 20278] open("/lib/lib-gnu-java-awt-peer-gtk.la", O_RDONLY) = -1 ENOENT (No
such file or directory)
[pid 20278] open("/usr/lib/lib-gnu-java-awt-peer-gtk.la", O_RDONLY) = -1 ENOENT
(No such file or directory)
[pid 20278] open("lib-gnu-java-awt-peer-gtk.la", O_RDONLY) = -1 ENOENT (No such
file or directory)
[pid 20278] access("/lib/lib-gnu-java-awt-peer-gtk.so", R_OK) = -1 ENOENT (No
such file or directory)
[pid 20278] access("/usr/lib/lib-gnu-java-awt-peer-gtk.so", R_OK) = 0
[pid 20278] open("/usr/lib/lib-gnu-java-awt-peer-gtk.so", O_RDONLY) = 4
java.awt.AWTError: Cannot load AWT toolkit: gnu.java.awt.peer.gtk.GtkToolkit
Caused by: java.lang.ClassNotFoundException: gnu.java.awt.peer.gtk.GtkToolkit
--
Summary: ClassNotFoundException: gnu.java.awt.peer.gtk.GtkToolkit
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: greenrd at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27265
[Bug libgcj/27265] ClassNotFoundException: gnu.java.awt.peer.gtk.GtkToolkit
--- Comment #1 from greenrd at gcc dot gnu dot org 2006-04-23 02:14 --- Looks like ltdl's configure script is setting the wrong default search path on x86_64. I found this patch that might help: http://dev.gentoo.org/~halcy0n/patches/patch/10_all_gcc4-libltdl-multilib.patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27265
[Bug libgcj/27368] New: [Xlib peer] Font.canDisplayUpTo throws UnsupportedOperationException
Until/unless bug 25375 is fixed, I'd like to use the Xlib AWT peer. But I can't
yet, because it doesn't implement the peer method for
java.awt.Font.canDisplayUpTo - it throws an UnsupportedOperationException.
(Incidentally, the gtk peer doesn't implement it either - it just returns a
dummy answer.)
I don't think that core Xlib provides a convenient API for this info, so maybe
the Xlib peer should use Xft for font stuff instead of core Xlib.
--
Summary: [Xlib peer] Font.canDisplayUpTo throws
UnsupportedOperationException
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: greenrd at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27368
[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
--- Comment #21 from greenrd at gcc dot gnu dot org 2006-01-09 17:32 --- For those wondering what aph is talking about, the hack he is referring to (or at least the initial proposal for it) is at https://www.redhat.com/archives/fedora-devel-java-list/2006-January/msg2.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
--- Additional Comments From greenrd at gcc dot gnu dot org 2005-09-15 00:27 --- Yes, I'm sure. I know what's going on here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
--- Comment #18 from greenrd at gcc dot gnu dot org 2005-10-23 10:44 --- Arno - you're missing the point. One of the test cases for this is rssowl (or more specifically, the SWT Browser widget, which embeds Mozilla on Linux). The Mozilla embedding subsystems (as opposed to the Mozilla Java plugin system, which is called OJI) don't know anything about CNI/JNI, so they can't be expected to create threads using the wrapped call to pthread_create. In general, AttachCurrentThread must be able to deal with arbitrary threads created by third-party native code which doesn't know about CNI or JNI. The current implementation cannot cope with arbitrary threads. See the discussion on the fedora Java mailing list. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
[Bug libgcj/24583] New: InetAddress.getLocalHost() returns broken InetAddress object when run in chroot
When a Java program is run in a chroot environment on Linux,
InetAddress.getLocalHost() returns a broken InetAddress object (broken in the
same way as it was in bug 17069).
Test case:
import java.net.InetAddress;
import java.net.UnknownHostException;
public class TestAddr {
public static void main (String args []) throws UnknownHostException {
InetAddress.getLocalHost ().getAddress ();
}
} // end of class TestAddr
The test case prints this inside the chroot:
Exception in thread "main" java.lang.NullPointerException
at java.net.InetAddress.getAddress() (/usr/lib/libgcj.so.6.0.0)
at TestAddr.main(java.lang.String[]) (Unknown Source)
at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0)
at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0)
and nothing when not in a chroot.
By using LD_LIBRARY_PATH I have verified that the brokenness _is_ triggered by
the chroot, not by the different versions of libc and libgcj that are
dynamically linked against when inside the chroot:
bash-3.00$ LD_LIBRARY_PATH=/mnt/rawhide/usr/lib:/mnt/rawhide/lib ldd
/mnt/rawhide/home/greenrd/testaddr
linux-gate.so.1 => (0xe000)
libgcc_s.so.1 => /mnt/rawhide/lib/libgcc_s.so.1 (0x00db1000)
libgcj.so.6 => /mnt/rawhide/usr/lib/libgcj.so.6 (0x0200)
libm.so.6 => /mnt/rawhide/lib/libm.so.6 (0x00354000)
libpthread.so.0 => /mnt/rawhide/lib/libpthread.so.0 (0x0039)
libz.so.1 => /mnt/rawhide/usr/lib/libz.so.1 (0x0037b000)
libdl.so.2 => /mnt/rawhide/lib/libdl.so.2 (0x0034e000)
libc.so.6 => /mnt/rawhide/lib/libc.so.6 (0xf7ed1000)
/lib/ld-linux.so.2 (0x00248000)
bash-3.00$ LD_LIBRARY_PATH=/mnt/rawhide/usr/lib:/mnt/rawhide/lib
/mnt/rawhide/home/greenrd/testaddr
bash-3.00$
The real /dev, /proc and /sys are mounted inside the chroot, and /sbin/ifconfig
can see all the network interfaces and their IPs when run as the same user from
inside the chroot, so it is not the case that the kernel is hiding this
information.
--
Summary: InetAddress.getLocalHost() returns broken InetAddress
object when run in chroot
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: greenrd at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24583
[Bug libgcj/24583] InetAddress.getLocalHost() returns broken InetAddress object when run in chroot
--- Comment #1 from greenrd at gcc dot gnu dot org 2005-10-30 00:21 --- Also, the hostname command does work inside the chroot - it returns the hostname of the real machine. So I don't think this is a reoccurrence of bug 17069. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24583
[Bug libgcj/24583] [4.0 only] InetAddress.getLocalHost() returns broken InetAddress object when local hostname cannot be resolved
--- Comment #2 from greenrd at gcc dot gnu dot org 2005-10-30 12:00 --- The real problem here was that I had a typo in my /etc/hosts, so the hostname could not be resolved. I've updated the bug summary. GNU classpath 0.18 implements the correct behaviour: $ jamvm TestAddr java.net.UnknownHostException: lcoyle1 at java.net.VMInetAddress.getHostByName (Native Method) at java.net.InetAddress.getAllByName (InetAddress.java:667) at java.net.InetAddress.getByName (InetAddress.java:622) at java.net.InetAddress.getLocalHost (InetAddress.java:777) at TestAddr.main (TestAddr.java:7) -- greenrd at gcc dot gnu dot org changed: What|Removed |Added Summary|InetAddress.getLocalHost() |[4.0 only] |returns broken InetAddress |InetAddress.getLocalHost() |object when run in chroot |returns broken InetAddress ||object when local hostname ||cannot be resolved http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24583
[Bug libgcj/25414] should update rmic
--- Comment #2 from greenrd at gcc dot gnu dot org 2006-02-27 16:59 --- Another reason to update rmic is that the current rmic ignores its -classpath argument. -- greenrd at gcc dot gnu dot org changed: What|Removed |Added CC||greenrd at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25414
[Bug libgcj/23495] java.lang.String.equals is suboptimal
--- Comment #11 from greenrd at gcc dot gnu dot org 2006-03-08 14:39 --- Sorry, I can't submit patches to libjava because I'm tainted (except for the packages that are new in Mustang, which I haven't seen). Even though this is a small change, I prefer to err on the side of caution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23495
