Some KDE applications 16.10 FTbFS with Qt 5.7.1 on arm64 and ppc64el

Bug #1656431 reported by Rik Mills
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
qtbase-opensource-src (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

libkf5kipi https://userbase.kde.org/KIPI
parley
kidentitymanagement
libkeduvocdocument

FTBFS with errors similar to the one shown at the bottom of this

As is the case with LP Bug #1654820, it seems likely that

kmail
kdepim-addons

would also fail in the same fashion, but the build depends are not yet in place to confirm that absolutely.

Again, this seems to be a case of qtbase using the gold linker, and I would surmise that as with amd64 etc, setting no gold linker for arm64 and ppc64el would resolve this.

no gold linker is already set in qtbase for amd64, i386, powerpc & armhf.

----------- log extract --------------

[ 56%] Linking CXX executable plaintexteditortest
cd /<<PKGBUILDDIR>>/obj-aarch64-linux-gnu/src/texteditor/plaintexteditor/autotests && /usr/bin/cmake -E cmake_link_script CMakeFiles/plaintexteditortest.dir/link.txt --verbose=1
/usr/bin/c++ -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++0x -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -pedantic -Wl,--enable-new-dtags -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,--as-needed -Wl,--no-undefined CMakeFiles/plaintexteditortest.dir/plaintexteditortest.cpp.o CMakeFiles/plaintexteditortest.dir/plaintexteditortest_automoc.cpp.o -o plaintexteditortest -Wl,-rpath,/<<PKGBUILDDIR>>/obj-aarch64-linux-gnu/src -rdynamic ../../../libKF5PimTextEdit.so.5.4.0.abi1 /usr/lib/aarch64-linux-gnu/libQt5Test.so.5.7.1 /usr/lib/aarch64-linux-gnu/libQt5Widgets.so.5.7.1 /usr/lib/aarch64-linux-gnu/libQt5Gui.so.5.7.1 /usr/lib/aarch64-linux-gnu/libQt5Core.so.5.7.1
/usr/lib/aarch64-linux-gnu/libQt5Gui.so.5.7.1:(*IND*+0x0): multiple definition of `__bss_start'
/usr/lib/aarch64-linux-gnu/libQt5Gui.so.5.7.1:(*IND*+0x0): multiple definition of `_edata'
/usr/lib/aarch64-linux-gnu/libQt5Gui.so.5.7.1:(*IND*+0x0): multiple definition of `_end'
/usr/lib/aarch64-linux-gnu/libQt5Core.so.5.7.1:(*IND*+0x0): multiple definition of `__bss_start'
/usr/lib/aarch64-linux-gnu/libQt5Core.so.5.7.1:(*IND*+0x0): multiple definition of `__bss_start'
/usr/lib/aarch64-linux-gnu/libQt5Core.so.5.7.1:(*IND*+0x0): multiple definition of `_edata'
/usr/lib/aarch64-linux-gnu/libQt5Core.so.5.7.1:(*IND*+0x0): multiple definition of `_edata'
/usr/lib/aarch64-linux-gnu/libQt5Core.so.5.7.1:(*IND*+0x0): multiple definition of `_end'
/usr/lib/aarch64-linux-gnu/libQt5Core.so.5.7.1:(*IND*+0x0): multiple definition of `_end'
//usr/lib/aarch64-linux-gnu/libQt5Network.so.5:(*IND*+0x0): multiple definition of `_edata'
//usr/lib/aarch64-linux-gnu/libQt5Network.so.5:(*IND*+0x0): multiple definition of `__bss_start'
//usr/lib/aarch64-linux-gnu/libQt5Network.so.5:(*IND*+0x0): multiple definition of `_end'
collect2: error: ld returned 1 exit status
/usr/lib/aarch64-linux-gnu/libQt5Gui.so.5.7.1:(*IND*+0x0): multiple definition of `__bss_start'
/usr/lib/aarch64-linux-gnu/libQt5Gui.so.5.7.1:(*IND*+0x0): multiple definition of `_edata'
/usr/lib/aarch64-linux-gnu/libQt5Gui.so.5.7.1:(*IND*+0x0): multiple definition of `_end'
/usr/lib/aarch64-linux-gnu/libQt5Core.so.5.7.1:(*IND*+0x0): multiple definition of `__bss_start'
/usr/lib/aarch64-linux-gnu/libQt5Core.so.5.7.1:(*IND*+0x0): multiple definition of `__bss_start'
/usr/lib/aarch64-linux-gnu/libQt5Core.so.5.7.1:(*IND*+0x0): multiple definition of `_edata'
/usr/lib/aarch64-linux-gnu/libQt5Core.so.5.7.1:(*IND*+0x0): multiple definition of `_edata'
/usr/lib/aarch64-linux-gnu/libQt5Core.so.5.7.1:(*IND*+0x0): multiple definition of `_end'
/usr/lib/aarch64-linux-gnu/libQt5Core.so.5.7.1:(*IND*+0x0): multiple definition of `_end'
//usr/lib/aarch64-linux-gnu/libQt5Network.so.5:(*IND*+0x0): multiple definition of `_edata'
//usr/lib/aarch64-linux-gnu/libQt5Network.so.5:(*IND*+0x0): multiple definition of `__bss_start'
//usr/lib/aarch64-linux-gnu/libQt5Network.so.5:(*IND*+0x0): multiple definition of `_end'
collect2: error: ld returned 1 exit status

Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

Let's tackle this as soon as the first transition is over so that we don't relaunch the currently passed autopkgtests.

Meanwhile there have been two binutils uploads too, and once https://launchpad.net/ubuntu/+source/binutils/2.27.90.20170114-1ubuntu1 is in release pocket this would be worth retrying.

Revision history for this message
Rik Mills (rikmills) wrote : Re: [Bug 1656431] Re: Some KDE applications 16.10 FTbFS with Qt 5.7.1 on arm64 and ppc64el

On 14/01/17 17:32, Timo Jyrinki wrote:
> Let's tackle this as soon as the first transition is over so that we
> don't relaunch the currently passed autopkgtests.
>
> Meanwhile there have been two binutils uploads too, and once
> https://launchpad.net/ubuntu/+source/binutils/2.27.90.20170114-1ubuntu1
> is in release pocket this would be worth retrying.

Well, I am ppa building against proposed, as this is staging for archive
uploads, and this still fails with that in place.

Yes, I was just recording this with the bug. Definitely one to tackle
once Qt has migrated the 1st time.

Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

Can you try adding a PPA dependency on https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2372/+packages (ci-train-ppa-service/2372 -> search -> click in +edit-dependencies PPA page)?

Do you have s390x builds in the PPA? That'd be the only one gold enabled still.

I've no problem with the setting otherwise but wondering why Debian is not affected. The normal GNU linker otherwise should be completely fine to use nowadays, and Qt upstream defaulting to gold on Linux might be a bit old-fashioned thing.

Revision history for this message
Rik Mills (rikmills) wrote :

On 16/01/17 11:39, Timo Jyrinki wrote:
> Can you try adding a PPA dependency on https://launchpad.net/~ci-train-
> ppa-service/+archive/ubuntu/2372/+packages (ci-train-ppa-service/2372 ->
> search -> click in +edit-dependencies PPA page)?
>
> Do you have s390x builds in the PPA? That'd be the only one gold enabled
> still.
>
> I've no problem with the setting otherwise but wondering why Debian is
> not affected. The normal GNU linker otherwise should be completely fine
> to use nowadays, and Qt upstream defaulting to gold on Linux might be a
> bit old-fashioned thing.
>

Yes, I can add that ppa dep and try some test rebuilds this afternoon.

Sadly we can't enable s390x in our ppas.

Debian has (a) yet to build any of the effect applications using Qt
5.7.1 as far as I know, and (b) their applications are currently ~
16.8.3 and have not yet tried to build these 16.12 apps AFAIK. So it is
possible they have yet to trip over these issues?

Revision history for this message
Rik Mills (rikmills) wrote :

On 16/01/17 11:39, Timo Jyrinki wrote:
> Do you have s390x builds in the PPA? That'd be the only one gold enabled
> still.

Perhaps to test s390x builds, once I have done my rebuilds on other
architectures this afternoon, you could then add our staging ppa
https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/staging-kdeapplications
as a dep to your ci-train one, and rebuild the effected packages for
s390x in there?

Revision history for this message
Rik Mills (rikmills) wrote :

On 16/01/17 11:39, Timo Jyrinki wrote:
> Can you try adding a PPA dependency on https://launchpad.net/~ci-train-
> ppa-service/+archive/ubuntu/2372/+packages (ci-train-ppa-service/2372 ->
> search -> click in +edit-dependencies PPA page)?

The packages that previously failed on arm64 and ppc64el now successful
build with that ppa and new Qt build as deps.

Revision history for this message
Rik Mills (rikmills) wrote :

Dmitry Shachnev copied some of the affected packages to a ppa that could build s390x and depending on Timo's test QT build ppa.

parley & libkeduvocdocument build on s390x seemingly ok.

kidentitymanagement & libkf5kipi are depwaiting there, as they needs a few other packages from KDE apps 16.12.1 in there before they can build.

So based on those preliminary, but quite limited results, seems that s390x builds are either not affected by this and a linker change in Qtbase is not needed, or is somehow of more smaller scope and has not been shown up by the few that have built.

I would lay bets if forced on the former of those 2, but would not be putting large sums on it. ;)

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package qtbase-opensource-src - 5.7.1+dfsg-2ubuntu2~1

---------------
qtbase-opensource-src (5.7.1+dfsg-2ubuntu2~1) zesty; urgency=medium

  * Disable gold linker also on arm64 and ppc64el (LP: #1656431)

 -- Timo Jyrinki <email address hidden> Mon, 16 Jan 2017 09:23:57 +0000

Changed in qtbase-opensource-src (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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