Skip to Content.
Sympa Menu

sm-discuss - [SM-Discuss] Qt5 mess

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Thomas Orgis <thomas-forum AT orgis.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: [SM-Discuss] Qt5 mess
  • Date: Fri, 24 Apr 2015 11:23:31 +0200

Hi,

I have some questions regarding the mess that Qt5 stuff is. This all
starts with the old conflict-with-the-current install thing. I have
consistent failure of qtbase after update of icu (before the icu
update, I also had consistent mangled symbol lookup failure that
probably was because of the old icu). This seems to be because there is
an existing install of qtbase in /opt/qt5 and that somehow brings in
the attempt to link to the non-existing icu library (soversion 54, not
55).

Well, all other qt5 spells have conflicts $SPELL to prevent such
braindead breakage, I presume. Adding a conflict to itself probably
would fix qtbase, too.

But I wonder: How does anyone ever to test builds of Qt5 for, you know,
developing it, if it always fails when a version of Qt5 is already
installed? I remember my old days of building Qt3 and KDE3 manually. I
never had issues with installed version conflicts. Since I installed
new stuff alongside old stuff to be able to test, I naturally installed
qt-x.y.z to /opt/qt-x.y.z. And, look at the building instructions for
Qt5:

http://doc.qt.io/qt-5/linux-building.html

(Yeah, the INSTALL file only points to outdated URLs instead of
providing any sensible information.).

Quote: By default, Qt is configured for installation in the
/usr/local/Qt-%VERSION% directory, but this can be changed
by using the -prefix option.

It's what they assume, too: You install to a separate prefix and I
strongly assume that this avoids this stupid self-conflict during build.

These instructions bring me to the second question: Why do we insist on
splitting the thing into several spells that need to be upgraded in
sync anyway? This increases maintainer burden and reduces the ratio of
tested to "hm, would have to cast that, too". Wouldn't we get the same
with one spell from qt-everywhere tarball with optional deps and
configuration questions about optional parts, with sub depends?

Are there parts that aren't included in the big upstream lump?

Anyhow, back to fixing the build somehow: I envision this

1. Install to /opt/qt5-$VERSION
This means all qt5 spells really should carry the same $VERSION!
Also includes setting QT5DIR to the versioned directory for the
qt5 spells, in case they use that variable.
2. Have /opt/qt5 as symlink to current /opt/qt5-$VERSION .
Alternative: Hack ld.so.conf and QT5DIR to always point to the
versioned prefix.
3. Ditch the self-conflicts, after testing that it really works.

Naturally, the migration path is a bit messy, one needs to dispel all
spells from /opt/qt5 before making that a symlink. But after that, I
envision that finally, I could have my many-hours-long sessions of
trying to get a new qt5 to build while still having the old one
installed and applications running.

What are your thoughts on that? I guess Treeve may have to say
something as the guy messing the most with Qt5 and KDE5 stuff.

I really want to get rid of having to dispel huge spells that need
yours to build before building them.

By the way: I was successfully able to build qtbase with prefix set
to /opt/qt5-5.4.1 and the old one still installed in /opt/qt5.

Now pondering how this all could work with the set of spells ... you
need careful triggering to ensure that all qt5 spells are updated
together to end up in the same prefix. Hence: A single qt5 spell would
be so much simpler.

Ideas?


Alrighty then,

Thomas


Attachment: pgpiLJNcKJgs6.pgp
Description: Digitale Signatur von OpenPGP




Archive powered by MHonArc 2.6.24.

Top of Page