libisoburn fails to build on powerpc

Bug #1571684 reported by Matthias Klose on 2016-04-18
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GLibC
Unknown
Unknown
glibc (Ubuntu)
Undecided
Unassigned
libisoburn (Ubuntu)
High
Unassigned

Bug Description

(gdb) run
Starting program: /home/doko/tmp/libisoburn-1.4.2/xorriso/.libs/xorriso -no_rc -version
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc-linux-gnu/libthread_db.so.1".
xorriso 1.4.2 : RockRidge filesystem manipulator, libburnia project.

xorriso 1.4.2
ISO 9660 Rock Ridge filesystem manipulator and CD/DVD/BD burn program
Copyright (C) 2015, Thomas Schmitt <email address hidden>, libburnia project.
xorriso version : 1.4.2
Version timestamp : 2015.11.28.140001
Build timestamp : -none-given-
libisofs in use : 1.4.2 (min. 1.4.2)
libjte in use : 1.0.0 (min. 1.0.0)
libburn in use : 1.4.2 (min. 1.4.2)
libburn OS adapter: internal GNU/Linux SG_IO adapter sg-linux
libisoburn in use : 1.4.2 (min. 1.4.2)
Provided under GNU GPL version 3 or later, due to libreadline license.
There is NO WARRANTY, to the extent permitted by law.

Program received signal SIGSEGV, Segmentation fault.
__GI__IO_wsetb (f=f@entry=0x1feccca0 <_IO_stdout_>, b=b@entry=0x0, eb=eb@entry=0x0, a=a@entry=0) at wgenops.c:105
105 wgenops.c: No such file or directory.

Matthias Klose (doko) wrote :

even the version 1.4.2-3 in the archive fails this way

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libisoburn - 1.4.2-4ubuntu1

---------------
libisoburn (1.4.2-4ubuntu1) xenial; urgency=medium

  * Don't call libtool with the --silent option.
  * debian/patches/0001-build-system.patch: do not pass a version script when
    building executables; this is meant for libraries, and its use appears to
    be breaking the build on powerpc (probably due to a toolchain regression).
    LP: #1571684.

 -- Matthias Klose <email address hidden> Mon, 18 Apr 2016 17:10:28 +0200

Changed in libisoburn (Ubuntu):
status: Confirmed → Fix Released
Thomas Schmitt (scdbackup) wrote :

Hi,

i downloaded libisoburn_1.4.2-4ubuntu1.debian.tar.xz and now look
at debian/patches/build-system.patch .

----------------------------------------------------------------

What is the motivation for removing "--silent" from libtool ?

----------------------------------------------------------------

Is it really correct to leave the experiment

     LDFLAGS="$LDFLAGS -Wl,--version-script=libisoburn/libisoburn.ver"
     AC_TRY_LINK([#include <stdio.h>], [printf("Hello\n");],
                 [vers_libs_test="yes"], [vers_libs_test="no"])

based on production of a binary rather than a shared library ?
(Not that i already knew how to test for library link success.)

----------------------------------------------------------------

Why did the minimal test run of xorriso succeed on Debian buildd
about 6 weeks ago ?

  https://buildd.debian.org/status/fetch.php?pkg=libisoburn&arch=powerpc&ver=1.4.2-4&stamp=1456745193

Older toolchain ?

----------------------------------------------------------------

The same gesture about --version-script is in libburn/acinclude.m4 .

The binary cdrskin is in about the same relation to libburn, as
xorriso is to libisoburn.

----------------------------------------------------------------

Have a nice day :)

Thomas

Thomas Schmitt (scdbackup) wrote :

Looks like you found a solution for
https://bugzilla.redhat.com/show_bug.cgi?id=1320305
on Fedora s390.

By running

  ./configure --disable-versioned-libs

i could keep the tests in libisoburn-1.4.2/releng/auto_isocontent
from crashing at the end of the xorriso runs.

Matthias Klose (doko) wrote :

> What is the motivation for removing "--silent" from libtool ?

what is the motivation to keep it? ;) I don't care, I'd like to see all available information in a build log instead of having to find out how to enable a verbose build when I'm looking at build failures.

I don't understand your second question. The question here is, why do executables need to be linked with --version-script at all? Of course glibc should correctly execute these.

no longer affects: xorriso
Matthias Klose (doko) wrote :

and yes, this happened after updating glibc 2.21 to 2.23

Thomas Schmitt (scdbackup) wrote :

> what is the motivation to keep it? ;)

Inherited autotools code. I change it only if i see a reason.

> I don't understand your second question.

When i test whether the option is supported by the linker, i do
this by applying it to a non-library binary.
AC_TRY_LINK() creates a tiny C program and links it using $LDFLAGS.
If it fails, vers_libs_test becomes "no" and --version-script= will
not be used.

The question is, whether this test actually has to try linking a
tiny library.

> why do executables need to be linked with --version-script at all?

Of course they should not. I will adopt your change upstream.

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.