Libguestfs - Aug 2018 - Re: [PATCH 4/4] java: Link with gnulib to resolve missing hash_free symbol.

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?
The java binding does not explicitly use the hash stuff from gnulib.

-- 
Pino Toscano

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)
> 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.

Nevertheless the error message (see above) is repeatable and
undeniable evidence that something is wrong.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

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