[Interest] Qt5 cannot be build on Debian Wheezy? GLIBCXX_3.4.20' not found

[René J.V. Bertin]

On Sunday January 18 2015 14:33:24 Thiago Macieira wrote:

> > Sorry, but that's just inacceptable, if not only because we're talking about
> > multi-user systems.
> 
> You may refuse to accept it, but it's reality.

It's not just me. It's widely considered bad practise and a flaw in the build system if a new version cannot be built with a previous version in place. How would systems like Gentoo and Arch do updates if this were common?

> You're forgetting that the Qt build is composed of several separate packages.

No, I'm not.

> If qtbase is installed already and then you proceed to build qtsvg, then qtsvg 
> needs to find the headers from the qtbase libraries in the target. So the prefix 
> is no longer unique: it's shared between your recently-installed qtbase and 
> your stale qtsvg.

That's where we're not on the same page. Of course it's true what you say, but in that case you're building qtsvg using the already installed new qmake (and a few other new components IIRC). And then things probably go fine too: you're bootstrapping the full build in manual steps, installing each component before proceeding to the next.

The problem is with a full build, like Qt 4.8 was built. The different components are built in the same order, but remain in the build directory, and thus qtsvg needs to find its headers from the qtbase in that build directory. NOT in the target.


> But if it needs to find headers from there, like qtsvg finding the already-
> installed qtbase, then the -I is necessary. Similar to -L flags.

But it doesn't ... A library or application being built has no business looking for its own headers outside of its source directory!

Imagine gcc or clang would do that ... you'd never be able to build a new version! And if this guideline would be extended to libraries, you'd not be able to use Qt Creator to build a new Qt, or do that running a KDE desktop ...

> I'm thinking of building qtsvg with the system qmake while qtsvg is already 
> installed in the target dir.

I understood, but again, that's not the issue. The issue is building the new qtsvg with the new qmake and the new qtbase which are all still in the build directory, but with a previous version installed in the target.

> or may not work. I don't know if it will try to find the headers from the 
> system for qtbase, but it's entirely possible it will. That is not a bug.

It's a conceptual bug or flaw, and should be documented.

> Patches accepted to implement and verify that it works.

:)
Here's my patch on OS X, a script that is called after calling configure and that does

replace --pattern "/opt/local/include/qt5" --with "" --files ${builddir}/qtwebengine/src/core/Release/obj/src/core/QtWebEngineCore.ninja ${builddir}/qtwebengine/src/core/Debug/obj/src/core/QtWebEngineCore.ninja

With that, one can do `make` and come back a few hours later.

> Trust me, we've tried and this problem is more complex than it seems.

Yes, I've seen that the qtwebengine build system is complex, but we're also talking about a single ninja build file that has the offending -I statement.

BTW, I don't know how ninja is pulled in to the build in that subcomponent, but I just realise that the header search path confusion could also arise if the wrong (= system) qmake is invoked. I suppose that if it is called with a full set of options to make sure everything required can be found in the build directory, but that probably wouldn't stop it from adding the system search paths.

R.