libvirt version 0.9.2-4ubuntu8 failed to build on armel

Repo out of sync?

doing a local testbuild here fails also in the tests but at a way earlier level (in the first testsuite)

As per Oliver's comment, setting to Confirmed.

Most (all?) tests fail with or because of this message (it makes the test output different than expected)
"Failed to read classid file: Object not found"
It is generated by libnl3 which is a dependency of libvirt and emitted when /etc/libnl/classid is not found. Creating this file makes the testsuite run successfully on ARM.
However this file does not exist on x86 either and there it is not a problem so the difference is that on ARM libvirt tests look for it when it should not (strace logs of ARM shows that indeed it is stat64()-d unsuccessfully, whereas on x86 it does not appear in the logs at all).

The bottom of lib/route/classid.c in the package libnl3 has

static void __init classid_init(void)
{
    int err, i;

    for (i = 0; i < CLASSID_NAME_HT_SIZ; i++)
        nl_init_list_head(&tbl_name[i]);

    if ((err = rtnl_tc_read_classid_file()) < 0)
        fprintf(stderr, "Failed to read classid file: %s\n", nl_geterror(err));
}

This __init function is maybe invoked on ARM but not on other archs and causes the different behaviour.

On ARM libvirt.so gets unnecessarily linked to libnl-route.so whereas it should depend only on libnl.so, causing the above __init function to be called (and cause an error message) in each app using libvirt.

This is the line that links libvirt. -lnl -lnl-route and the other libnl sublibs are there, but only -lnl is used by libvirt.
Still nl-route gets linked as well.

$ pkg-config --libs libnl-3.0
-lnl -lnl-route -lnl-nf -lnl-genl -lnl-cli

libtool: link: gcc -std=gnu99 -shared -Wl,--whole-archive ./.libs/libvirt_util.a ./.libs/libvirt_conf.a ./.libs/libvirt_cpu.a ./.libs/libvirt_vmx.a ./.libs/libvirt_driver.a ./.libs/libvirt_driver_test.a ./.libs/libvirt_driver_remote.a ./.libs/libvirt_driver_openvz.a ./.libs/libvirt_driver_vmware.a ./.libs/libvirt_driver_nwfilter.a ./.libs/libvirt_driver_security.a ../gnulib/lib/.libs/libgnu.a -Wl,--no-whole-archive -lcap-ng -lnl -lnl-route -lnl-nf -lnl-genl -lnl-cli -ldevmapper /usr/lib/arm-linux-gnueabi/libgnutls.so -lgcrypt -lsasl2 -lapparmor -lpthread -lxml2 -ldl -Wl,--version-script=libvirt.syms -Wl,-Bsymbolic-functions -Wl,-soname -Wl,libvirt.so.0 -o .libs/libvirt.so.0.9.2

Same with gold, or binutils 2.21.1 from the ubuntu-toolchain-r PPA.

Dropping -lnl-route from the command line is the only way to not have it linked in libvirt.so.

$ awk 'NF==1 && $NF == "/usr/lib/libnl.so"' ld.log | wc -l
29
$ awk 'NF==2 && $NF == "/usr/lib/libnl.so"' ld.log
lrint@GLIBC_2.4 /usr/lib/libnl.so

^^^ this doesn't seem to be correct

$ awk 'NF==1 && $NF == "/usr/lib/libnl-route.so"' ld.log | wc -l
23
$ awk 'NF==2 && $NF == "/usr/lib/libnl-route.so"' ld.log
(no output)

Matthias, thanks for the objects.

I can't see a way of getting the info we wanted on the command line,
but I hacked up a linker to print the symbol that causes each as-needed
object to be pulled in. The one that was causing libnl-route.so.3 to be
pulled in was __aeabi_d2ulz.

__aeabi_d2ulz is normally provided by libgcc. I notice that libnl-route
isn't linked against libgcc.so though, and presumably used the static
version instead. I wonder whether that was from linking libnl-route
with --static-libgcc, from some libtool weirdness, or something else.
A workaround would be to link against libgcc.so instead.

The bug is that __aeabi_d2ulz is defined as an alias of __fixunsdfdi.
__fixunsdfdi is correctly marked as hidden in libgcc.a,
but __aeabi_d2ulz isn't. So this is indeed a GCC bug.

The bug comes from config/arm using asm statements to define an alias,
rather than using an alias attribute. So even though libgcc2 tries the
belt-and-braces approach of -fvisibility=hidden and "GCC visibility"
pragmas, the alias still ends up having default visibility. Will test a
fix overnight.

Marking this as high since it's an ABI problem.

This bug was fixed in the package libvirt - 0.9.2-4ubuntu9

---------------
libvirt (0.9.2-4ubuntu9) oneiric; urgency=low

  * Fix build failure on ARM, working around a GCC issue. LP: #823711.
 -- Matthias Klose <email address hidden> Mon, 15 Aug 2011 16:00:53 +0200

This bug was fixed in the package gcc-4.5 - 4.5.3-6ubuntu1

---------------
gcc-4.5 (4.5.3-6ubuntu1) oneiric; urgency=low

  * Re-enable the build using Linaro on powerpc. LP: #768921.

gcc-4.5 (4.5.3-6) unstable; urgency=low

  * Update to SVN 20110818 (r177845) from the gcc-4_5-branch.
    - Fix PR target/50001, PR fortran/42051, PR fortran/43896,
      PR fortran/49962.

  [ Aurelien Jarno ]
  * Add s390x support

  [ Marcin Juszkiewicz ]
  * Fixes for multilib cross builds. LP: #816852.

  [ Matthias Klose ]
  * Update the Linaro support to the 4.5-2011.08 release.
    - Fix build on powerpc. LP: #768921.
  * Fix [ARM] PR target/50090: aliases in libgcc.a with default visibility,
    taken from the trunk. LP: #823711.
 -- Matthias Klose <email address hidden> Thu, 18 Aug 2011 09:24:26 +0200

This bug was fixed in the package gcc-4.6 - 4.6.1-7ubuntu2

---------------
gcc-4.6 (4.6.1-7ubuntu2) oneiric; urgency=low

  * Update to SVN 20110823 (r177982) from the gcc-4_6-branch.
    Fix PR fortran/49792, PR tree-optimization/48739, PR target/50092,
    PR c++/50086, PR c++/50054, PR fortran/50050, PR fortran/50130,
    PR fortran/50129, PR fortran/49792, PR fortran/50109.

  * Properly disable multilib builds for selected libraries on armel and armhf.
  * Update and re-enable the gcc-ice patch.
  * Update and re-enable the gcc-cloog-dl patch.
  * Fix [ARM] PR target/50090: aliases in libgcc.a with default visibility,
    taken from the trunk. LP: #823711.
  * Re-work the multiarch patches.
  * Break older gcj-4.6 and gnat-4.6 versions, changed gcc_lib_dir.
  * Omit the target alias from the go libdir.
  * Linaro updates from the 4.6-2011.07-stable branch.
 -- Matthias Klose <email address hidden> Tue, 23 Aug 2011 09:26:22 +0200

Will be picked up by Andrew's release branch merge.

The change is in the release candiate.

Will get pulled into stable with the release branch merge.