Re: [Xen-devel] tools/libxl: fix compilation and link errors on NetBSD

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2013-05-15 at 12:31 +0200, Christoph Egger wrote:
> I see the following link failure:
> 
> gcc    -pthread -o testidl testidl.o libxlutil.so 
> /home/chegger/xen.git/tools/libxl/../../tools/libxl/libxenlight.so 
> -Wl,-rpath-link=/home/chegger/xen.git/tools/libxl/../../tools/libxc 
> -Wl,-rpath-link=/home/chegger/xen.git/tools/libxl/../../tools/xenstore  
> /home/chegger/xen.git/tools/libxl/../../tools/libxc/libxenctrl.so  
> -L/usr/pkg/lib

> ld: warning: libyajl.so.2, needed
> by /home/chegger/xen.git/tools/libxl/../../tools/libxl/libxenlight.so,
> not found (try using -rpath or -rpath-link)

This is exactly as I described, at length, below. The libxenlight
library uses yajl and is (or should be) linked against it. testidl does
not itself use yajl and should not need to be explicitly linked against
it.

This failure should not be worked around by needlessly linking yajl into
testidl.

You likely need to investigate your toolchain to figure out what the
correct fix is, which may involve changing how libxenlight.so is linked
on your system.

> > This variable specifies the linker line which an application linking
> > libxl is required to use. Unless that application is using yajl itself
> > then it doesn't need -lyajl since the library is correctly linked to the
> > libyajl itself (via ELF DT_NEEDED).
> > 
> > If an application does use yajl itself (as xl does) then it should also
> > link against the library itself, which is what xl does (or did before
> > you changed it below), but it should not get this from
> > LDLIBS_libxenlight.
> > 
> > testidl.c doesn't use yajl directly, so it shouldn't need to link
> > against libjyajl itself directly AFAICT. The fact that testidl and xl
> > use different libraries is exactly the reason why their link lines are
> > "inconsistent".
> > 
> > With GNU ld this relates the the --as-needed option, perhaps you need to
> > find similar functionality for your linker?
> > 
> > Also APPEND_LDFLAGS should be in the final app link only, no need to add
> > it here.
> > 
> >>  SHLIB_libxenlight  = -Wl,-rpath-link=$(XEN_XENLIGHT)
> >>  
> >>  CFLAGS += -D__XEN_TOOLS__
> >> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> >> index cf214bb..c65c11e 100644
> >> --- a/tools/libxl/Makefile
> >> +++ b/tools/libxl/Makefile
> >> @@ -189,7 +189,7 @@ libxlutil.a: $(LIBXLU_OBJS)
> >>         $(AR) rcs libxlutil.a $^
> >>  
> >>  xl: $(XL_OBJS) libxlutil.so libxenlight.so
> >> -       $(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so 
> >> $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) -lyajl $(APPEND_LDFLAGS)
> >> +       $(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so 
> >> $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
> > 
> > As explained above you shouldn't be changing this. I suppose it might be
> > possible that reordering the yajl here is a correct fix for your issue,
> > but having not seen it I can't really say.
> 
> This change is just that -lyajl is not redundant here.

This change *is* redundant because as I explained you should not be
changing LDLIBS_libxenlight.

> Adding -lyajl to testidl like to xl w/o my patch doesn't work for me. I see 
> the
> same error as above.

Adding -lyajl to the testidl link line would also be wrong, for the same
reasons.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel