Thread: [Sablevm-developer] Re: Bug#164363: libsablevm-native1: UnsatisfiedLinkError when using AWT
Brought to you by:
egagnon
From: Grzegorz P. <gr...@se...> - 2002-10-13 18:27:49
|
W li=B6cie z pi=B1, 11-10-2002, godz. 21:43, Toby Speight pisze:=20 > Package: libsablevm-native1 > Version: 1.0.4-1 > Severity: important > Tags: patch >=20 > When linking libgnu-java-awt-peer-gtk, its dependencies are not > specified, meaning that it cannot be dynamically loaded at runtime, > resulting in an UnsatisfiedLinkError at toolkit initialisation: >=20 > /-------- > | loading gtkpeer > | java.lang.UnsatisfiedLinkError: Could not load library /usr/lib/sablev= m/libgnu-java-awt-peer-gtk-1.0.1.so > | at java.lang.Runtime.load(Runtime.java:633) > | at java.lang.Runtime.loadLibrary(Runtime.java:656) > | at java.lang.System.loadLibrary(System.java:620) > | at gnu.java.awt.peer.gtk.GtkToolkit.static{}(GtkToolkit.java:74) > | ... > \-------- Strange - why do I see 1.0.1 in above error (and 1.0.4 is mentioned as the "Version:")? I know that sablevm's build system has some problem that results in exaclty such problems (runtime tries to load lib of another version which was installed in the system during the build). > I enclose a patch that adds the right dependencies (works for me). The more strange is why this didn't work and why your change fixes it. Are you sure that "just rebuilding" doesn't solve the problem? I think it won't solve it (even if the versions were equal) and you expirience the same thing as this: http://sourceforge.net/mailarchive/forum.php?thread_id=3D999972&forum_id=3D= 4154 > I'm not an automake wizard by any means, so it's possible that the > ld flags for the GTK libraries could be put into @LDFLAGS@ rather > than into Makefile.in, but if that's the case then this should at > least give you a start. >=20 > My Java program needs a java.awt.Image implementation, so it falls over > when it looks for libgnu-java-awt-image, but it definitely manages to > load libgnu-java-awt-peer-gtk. (Sadly, I can't contribute to the image > implementation because I use Sun-licensed Java sources at work). >=20 > When debugging this, I found it helpful to retrieve and print the > error message from lt_dlopen by adding some following lines at line > 211 of java_lang_Runtime.c in the sablevm package giving the following > replacement for the handle=3D=3DNULL test: >=20 > /-------- > | if (handle =3D=3D NULL) > | { > | char *error =3D lt_dlerror(); > | if (error) > | _svmf_printf (env, stdout, "lt_dlopen: %s\n", error); > | else > | _svmf_printf (env, stdout, "lt_dlopen: NULL\n"); > | _svmm_gfree_utf_chars (filename); > | goto end; > | } > \-------- >=20 >=20 > It might be nice to find a way to propagate the string retrieved from > lt_dlerror back into the Java world, to give a more informative > message for the exception. Yes, it seems that SableVM has hard times delivering meaningful error messages to the user (unfortunatelly). I hope it'll be improved when more important problems are solved. > --- sablevm-nativelib-1.0.4/src/gnu-java-awt-peer-gtk/Makefile.in 2= 002-08-24 17:22:57 +0100 > +++ sablevm-nativelib-1.0.4-tms/src/gnu-java-awt-peer-gtk/Makefile.in 2= 002-10-11 20:10:18 +0100 > @@ -174,7 +174,7 @@ > DEFS =3D @DEFS@ > DEFAULT_INCLUDES =3D -I. -I$(srcdir) -I$(top_builddir)/src/include > CPPFLAGS =3D @CPPFLAGS@ > -LDFLAGS =3D @LDFLAGS@ > +LDFLAGS =3D @LDFLAGS@ $(shell gtk-config --libs gtk gthread) > LIBS =3D @LIBS@ > depcomp =3D $(SHELL) $(top_srcdir)/depcomp > am__depfiles_maybe =3D depfiles I'll try to check this problem (and your solution) soon and report my expiriences. Thanks for the patch.=20 Best regards Grzegorz B. Prokopski PS: I am Cc:ing SableVM devel for eventuall comments. For ex. is the approach w/ calling gtk-config right and eventually how should it be done in more "autotoolsed" way? |
From: Etienne M. G. <eti...@uq...> - 2002-10-14 01:12:27
|
On Sun, Oct 13, 2002 at 08:27:35PM +0200, Grzegorz Prokopski wrote: > > > > It might be nice to find a way to propagate the string retrieved from > > lt_dlerror back into the Java world, to give a more informative > > message for the exception. > Yes, it seems that SableVM has hard times delivering meaningful error > messages to the user (unfortunatelly). I hope it'll be improved > when more important problems are solved. We should definitely add this to the TODO list. Etienne -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
From: Toby S. <str...@gm...> - 2002-10-14 10:58:07
|
0> In article <103...@gr...>, 0> Grzegorz Prokopski <URL:mailto:gr...@se...> ("Grzegorz") wrote: Grzegorz> W li=B6cie z pi=B1, 11-10-2002, godz. 21:43, Toby Speight = pisze: >> /-------- >> | loading gtkpeer >> | java.lang.UnsatisfiedLinkError: Could not load library = /usr/lib/sablevm/libgnu-java-awt-peer-gtk-1.0.1.so >> | at java.lang.Runtime.load(Runtime.java:633) >> | at java.lang.Runtime.loadLibrary(Runtime.java:656) >> | at java.lang.System.loadLibrary(System.java:620) >> | at gnu.java.awt.peer.gtk.GtkToolkit.static{}(GtkToolkit.java:74) >> | ... >> \-------- Grzegorz> Strange - why do I see 1.0.1 in above error (and 1.0.4 is Grzegorz> mentioned as the "Version:")? I cut-and-pasted from the wrong place (whilst investigating, Google turned up your message at [1], and I accidentally copied from there rather than from my shell buffer). I did indeed see 1.0.4 in the error message. Sorry for causing confusion. [1] = <URL:http://sourceforge.net/mailarchive/forum.php?thread_id=3D999972&for= um_id=3D4154> >> I enclose a patch that adds the right dependencies (works for me). Grzegorz> The more strange is why this didn't work and why your change Grzegorz> fixes it. Are you sure that "just rebuilding" doesn't solve Grzegorz> the problem? Yes, I am sure that simply rebuilding doesn't solve it - that was the first thing I tried. With the current 1.0.4, the GTK AWT library doesn't refer to the libraries that provide GTK: /-------- | .../sablevm-nativelib-1.0.4$ ldd = debian/libsablevm-native1/usr/lib/sablevm/libgnu-java-awt-peer-gtk.so | libc.so.6 =3D> /lib/libc.so.6 (0x4001d000) | /lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x80000000) \-------- With my patch, the GTK and GThread libraries are (dynamically) linked in to satisfy dependencies on gdk_threads_mutex, gdk_root_window, gthread_init, etc.: /-------- | .../sablevm-nativelib-1.0.4-tms$ ldd = debian/libsablevm-native1/usr/lib/sablevm/libgnu-java-awt-peer-gtk.so | libgtk-1.2.so.0 =3D> /usr/lib/libgtk-1.2.so.0 (0x4001d000) | libgdk-1.2.so.0 =3D> /usr/lib/libgdk-1.2.so.0 (0x40142000) | libgmodule-1.2.so.0 =3D> /usr/lib/libgmodule-1.2.so.0 = (0x40175000) | libgthread-1.2.so.0 =3D> /usr/lib/libgthread-1.2.so.0 = (0x40178000) | libglib-1.2.so.0 =3D> /usr/lib/libglib-1.2.so.0 (0x4017b000) | libpthread.so.0 =3D> /lib/libpthread.so.0 (0x4019d000) | libdl.so.2 =3D> /lib/libdl.so.2 (0x401b2000) | libXi.so.6 =3D> /usr/X11R6/lib/libXi.so.6 (0x401b5000) | libXext.so.6 =3D> /usr/X11R6/lib/libXext.so.6 (0x401bd000) | libX11.so.6 =3D> /usr/X11R6/lib/libX11.so.6 (0x401ca000) | libm.so.6 =3D> /lib/libm.so.6 (0x40284000) | libc.so.6 =3D> /lib/libc.so.6 (0x402a5000) | /lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x80000000) \-------- I arrived at my patch initially by adding the libraries one at a time to Makefile each time I discovered an unresolved symbol, but luckily I remembered the existence of gtk-config before moving the fix to Makefile.in. Grzegorz> I think it won't solve it (even if the versions were equal) Grzegorz> and you experience the same thing as this: Grzegorz> = http://sourceforge.net/mailarchive/forum.php?thread_id=3D999972&forum_id= =3D4154 Yes, that's exactly the issue this patch solves. :-) Grzegorz> PS: I am Cc:ing SableVM devel for eventuall comments. I'm not on this list, so any questions, etc., for me should be CCed to = me (or to <16...@bu...> which I will check very infrequently). N.B. - don't follow-up to <su...@bu...>! |
From: Grzegorz P. <gr...@se...> - 2002-10-15 22:37:57
Attachments:
TestAWT.java
Test.java
|
W li=B6cie z pon, 14-10-2002, godz. 12:57, Toby Speight pisze:=20 > With my patch, the GTK and GThread libraries are (dynamically) linked > in to satisfy dependencies on gdk_threads_mutex, gdk_root_window, > gthread_init, etc.: [...] > Yes, that's exactly the issue this patch solves. :-) OKay, it kinda worked, but now I am getting this (1.0.4): XXXXXXX TestAWT.class INSET:java.awt.Insets(top=3D0,bottom=3D0,left=3D0,right=3D0) loading gtkpeer init TRYING TO GET INTO GTKMAIN ACQUIRED LOCK TO RUN GTKMAIN 262 sablevm: INTERNAL ERROR (source file "native_interface.c", line 24655): todo [and commandline returned w/o any effect] XXXXXXX Test.class loading gtkpeer init TRYING TO GET INTO GTKMAIN ACQUIRED LOCK TO RUN GTKMAIN [and it seemed to eat 100% CPU here while hanging] I am attaching both (source) files used for testing. AFAIR they were in GNU ClassPath CVS repository, but were removed from there. Toby - do you have ANY (even trivial) Java app using AWT that runs w/ SableVM after applying your patch? Could you send it please? I would upload new 1.0.4 w/ your patch if I knew that it really helps to get anything really working. Best regards Grzegorz B. Prokopski PS: Etienne - please treat it as a bugreport (or feature request?) (I mean that INTERNAL ERROR above). You were saying you work on filling the holes in JNI interface, so maybe it's already fixed in your current version? |
From: Toby S. <str...@gm...> - 2002-10-24 13:45:51
|
0> In article <103...@gr...>, 0> Grzegorz Prokopski <URL:mailto:gr...@se...> ("Grzegorz") wrote: Grzegorz> OKay, it kinda worked, but now I am getting this (1.0.4): Grzegorz> Grzegorz> XXXXXXX TestAWT.class Grzegorz> INSET:java.awt.Insets(top=0,bottom=0,left=0,right=0) Grzegorz> loading gtkpeer Grzegorz> init Grzegorz> TRYING TO GET INTO GTKMAIN Grzegorz> ACQUIRED LOCK TO RUN GTKMAIN Grzegorz> 262 Grzegorz> sablevm: INTERNAL ERROR (source file "native_interface.c", line 24655): Grzegorz> todo Grzegorz> [and commandline returned w/o any effect] I get the same with my simplest AWT test class (a Frame, a Label, and a WindowAdapter) - we're now waiting for monitor_enter and friends to be implemented in sablevm. Which is an improvement from a development perspective, if not immediately useful to users. Pretty much everything in AWT uses thread synchronisation somewhere or other (I expect, not having examined classlib), so we're not going to have a working AWT application for a while. :-( |
From: Etienne M. G. <eg...@j-...> - 2002-10-24 14:05:46
|
On Thu, Oct 24, 2002 at 02:45:34PM +0100, Toby Speight wrote: > Pretty much everything in AWT uses thread synchronisation somewhere or > other (I expect, not having examined classlib), so we're not going to > have a working AWT application for a while. :-( Threads and synchronizations ARE very much functional within SableVM. It's just the JNI "wrapper" that calls the internal synchro stuff that is yet missing. I'm just too busy at the moment (writing papers, teaching courses, catching up with all the late stuff that was delayed until I submitted my Ph.D. thesis late September). So, there's still some hope to get things up and running in the not too far future. What will help is when the evaluation of my thesis is done, as I will put it online, giving a nice reference for developers wanting to help write code within the VM itself. Etienne > > > ------------------------------------------------------- > This sf.net email is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com/javavote > _______________________________________________ > Sablevm-developer mailing list > Sab...@li... > https://lists.sourceforge.net/lists/listinfo/sablevm-developer -- Etienne M. Gagnon eg...@j-... SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |