Perhaps not directly relevant to your bug, but I found a similar problem with
our custom-build Debian package for xen-4.0.1:
libxl doesn't link to libxenstore itself, but if you want to use libxl with
any program, you have to link libxenstore as well, as libxl uses the function
from libxenstore. This confuses dpkg-shlibdeps, which resolves the
shared-library-dependencies on a per-symbol basis:
* xs_daemon_destroy_postfork() is only available from >= 4.0.0~rc4.
* libxl uses it, but isn't directly linked to libxenstore, so dpkg-shlibdeps
isn't able to determin, that libxenstore from >= 4.0.0~rc4 is needed during
runtime. Instead it just declares a dependency on libxenstore.
* Any program (currently only xl) using libxl might crash during runtime as
soon as xs_daemon_destroy_postfork() while an old libxenstore is installed.
Something like the following pseudo-patch solved the problem by already
linking libxl to libxenstore:
@ xen-4.0.1/tools/libxl/Makefile:62
libxenlight.so.$(MAJOR).$(MINOR): $(LIBXL_OBJS)
- $(CC) $(CFLAGS) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenlight.so.
$(MAJOR) $(SHLIB_CFLAGS) -o $@ $^
+ $(CC) $(CFLAGS) $(LDFLAGS) $(LDFLAGS_libxenstore) -Wl,
$(SONAME_LDFLAG) -Wl,libxenlight.so.$(MAJOR) $(SHLIB_CFLAGS) -o $@ $^
Alternatively incrementing the minior version of libxenstore would have been a
good idea, since a new function was added.
Sincerely
Philipp Hahn
