libvirt version 0.9.2-4ubuntu8 failed to build on armel

Reported by Ricardo Salveti on 2011-08-10
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Linaro Binutils
Undecided
Unassigned
Linaro GCC
High
Richard Sandiford
4.5
High
Richard Sandiford
4.6
High
Richard Sandiford
4.6-2011.07-stable
High
Michael Hope
gcc
Fix Released
Medium
gcc-4.5 (Ubuntu)
Undecided
Unassigned
Oneiric
Undecided
Unassigned
gcc-4.6 (Ubuntu)
High
Unassigned
Oneiric
High
Unassigned
libvirt (Ubuntu)
Medium
Jani Monoses
Oneiric
Medium
Jani Monoses

Bug Description

libvirt version 0.9.2-4ubuntu8 failed to build on armel
Link to failed build: https://launchpad.net/ubuntu/+source/libvirt/0.9.2-4ubuntu8/+build/2673838

Direct link to the build log: https://launchpad.net/ubuntu/+source/libvirt/0.9.2-4ubuntu8/+build/2673838/+files/buildlog_ubuntu-oneiric-armel.libvirt_0.9.2-4ubuntu8_FAILEDTOBUILD.txt.gz

This log snippet might be of interest, since it triggered the matcher 'Purging chroot-autobuild'.
Excerpt 5798 lines into the build log:

      ................. 57 OK
PASS: cputest
=======================================
10 of 48 tests failed
(1 test was not run)
Please report to <email address hidden>
=======================================
make[3]: *** [check-TESTS] Error 1
make[3]: Leaving directory `/build/buildd/libvirt-0.9.2/tests'
make[2]: *** [check-am] Error 2
make[2]: Leaving directory `/build/buildd/libvirt-0.9.2/tests'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/build/buildd/libvirt-0.9.2'
make: *** [debian/stamp-makefile-check] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
******************************************************************************
Build finished at 20110809-1359
FAILED [dpkg-buildpackage died]
Purging chroot-autobuild/build/buildd/libvirt-0.9.2

Ricardo Salveti (rsalveti) wrote :

Repo out of sync?

Jani Monoses (jani) on 2011-08-11
Changed in libvirt (Ubuntu):
assignee: nobody → Jani Monoses (jani)
Oliver Grawert (ogra) wrote :

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

Ursula Junque (ursinha) wrote :

As per Oliver's comment, setting to Confirmed.

Changed in libvirt (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium
Jani Monoses (jani) wrote :

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.

Jani Monoses (jani) wrote :

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.

Jani Monoses (jani) wrote :

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

Jani Monoses (jani) wrote :

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.

Matthias Klose (doko) wrote :
Matthias Klose (doko) wrote :

$ 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 Klose (doko) wrote :
Richard Sandiford (rsandifo) wrote :

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.

Changed in binutils-linaro:
status: New → Invalid
Changed in gcc-linaro:
status: New → Confirmed
Richard Sandiford (rsandifo) wrote :

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.

Changed in gcc-linaro:
assignee: nobody → Richard Sandiford (rsandifo)
importance: Undecided → High
Richard Sandiford (rsandifo) wrote :

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

EABI functions like __aeabi_f2ulz are defined as aliases
of standard libgcc functions like __fixunssfdi. In libgcc.a,
the standard function gets the correct hidden visibility,
but the alias retains default visibility. This means that
DSOs linked against libgcc.a may end up exporting the
libgcc.a definition of __aeabi_f2ulz.

The bug is that bpabi-lib.h uses an asm statement to define
an alias, so the standard ways of forcing hidden visibility
at the C level have no effect.

Testing a fix.

Launchpad Janitor (janitor) wrote :

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

Changed in libvirt (Ubuntu):
status: Confirmed → Fix Released
Matthias Klose (doko) on 2011-08-15
affects: binutils (Ubuntu) → gcc-4.6 (Ubuntu)
Changed in gcc-4.6 (Ubuntu Oneiric):
importance: Undecided → High
status: New → Triaged

Author: rsandifo
Date: Wed Aug 17 11:13:20 2011
New Revision: 177826

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177826
Log:
libgcc/
 PR target/50090
 * config/arm/bpabi-lib.h (RENAME_LIBRARY): Use a C-level alias
 instead of an assembly one.

Modified:
    trunk/libgcc/ChangeLog
    trunk/libgcc/config/arm/bpabi-lib.h

Launchpad Janitor (janitor) wrote :

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

Changed in gcc-4.5 (Ubuntu Oneiric):
status: New → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in gcc-4.6 (Ubuntu Oneiric):
status: Triaged → Fix Released
Michael Hope (michaelh1) on 2011-08-23
Changed in gcc-linaro:
status: Confirmed → In Progress
Changed in gcc:
importance: Unknown → Medium
status: Unknown → In Progress

Author: rsandifo
Date: Wed Aug 24 17:21:48 2011
New Revision: 178043

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178043
Log:
libgcc/
 PR target/50090
 * config/arm/bpabi-lib.h (RENAME_LIBRARY_SET): Delete.
 (RENAME_LIBRARY): Use a C-level alias instead of an assembly one.

Modified:
    branches/gcc-4_6-branch/libgcc/ChangeLog
    branches/gcc-4_6-branch/libgcc/config/arm/bpabi-lib.h

Author: rsandifo
Date: Fri Aug 26 08:32:06 2011
New Revision: 178097

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178097
Log:
gcc/
 PR target/50090
 * config/arm/bpabi.h (RENAME_LIBRARY_SET): Delete.
 (RENAME_LIBRARY): Use a C-level alias instead of an assembly one.

Modified:
    branches/gcc-4_5-branch/gcc/ChangeLog
    branches/gcc-4_5-branch/gcc/config/arm/bpabi.h

Michael Hope (michaelh1) on 2011-08-30
Changed in gcc-linaro:
milestone: none → 4.6-2011.09
Michael Hope (michaelh1) wrote :

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

Michael Hope (michaelh1) wrote :

The change is in the release candiate.

Michael Hope (michaelh1) wrote :

Will get pulled into stable with the release branch merge.

Fix applied to 4.5, 4.6 and trunk.

Changed in gcc:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.