On Wednesday, 22 August 2018 16:16:40 CEST Richard W.M. Jones wrote: > On Wed, Aug 22, 2018 at 12:56:47PM +0200, Pino Toscano wrote: > > On Tuesday, 14 August 2018 15:42:13 CEST Richard W.M. Jones wrote: > > > --- > > > java/Makefile.am | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > diff --git a/java/Makefile.am b/java/Makefile.am > > > index 81c20f266..1bad9a853 100644 > > > --- a/java/Makefile.am > > > +++ b/java/Makefile.am > > > @@ -122,7 +122,8 @@ libguestfs_jni_la_CFLAGS = \ > > > libguestfs_jni_la_LIBADD = \ > > > $(top_builddir)/common/structs/libstructs.la \ > > > $(top_builddir)/common/utils/libutils.la \ > > > - $(top_builddir)/lib/libguestfs.la > > > + $(top_builddir)/lib/libguestfs.la \ > > > + $(top_builddir)/gnulib/lib/libgnu.la > > > > Hmm what's the exact error in this case? On which platform? > > Fedora 28: > > Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/rjones/d/libguestfs-master/java/.libs/libguestfs_jni.so.1.39.8: /home/rjones/d/libguestfs-master/java/.libs/libguestfs_jni.so.1.39.8: undefined symbol: hash_free > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857) > at java.lang.Runtime.loadLibrary0(Runtime.java:870) > at java.lang.System.loadLibrary(System.java:1122) > at com.redhat.et.libguestfs.GuestFS.<clinit>(GuestFS.java:51) > at Bindtests.main(Bindtests.java:33) On my Fedora 28, the java tests work fine in both my work copy, and in a new checkout I tried with. I use no particular build flags/settings. > > The java binding does not explicitly use the hash stuff from gnulib. > > It uses the CLEANUP_* macros, and they appear to pull in the hash_free > function (via guestfs_int_cleanup_hash_free). > > What does confuse me is why linking with libutils.a causes the > hash_free dependency to be pulled in, since if my understanding of > static linking is correct it should only pull in whole object files > which are actually used. This I cannot explain. Yes, that was my understanding as well. > Nevertheless the error message (see above) is repeatable and > undeniable evidence that something is wrong. As I said, unfortunately not for me :-/ The thing that makes me puzzling about this is that I actually saw this issue in the past, on a different system (an older version of RHEL 7). But then, trying again later on basically the same system did not show me the issue. As additional data point: so far we did not receive (at least to my knowledge, of course) reports of the java binding broken because of this. Surely this binding is not one of the most used ones, but still... -- Pino Toscano
Description: This is a digitally signed message part.