[Sablevm-developer] Re: Bug#164363: libsablevm-native1: UnsatisfiedLinkError when using AWT

[Grzegorz P. <gr...@se...>]

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?