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

[Thiago Macieira]

On Monday 19 January 2015 00:25:38 René J.V. Bertin wrote:
> > You're forgetting that the Qt build is composed of several separate
> > packages.
> No, I'm not.

You are, when you say this:

> 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.

It's not a different build. It's just a convenience build of multiple packages. 
The fact that we provide a Makefile for the top dir should distract you from 
the fact that you're building multiple packages.

Which in turn means they may behave as if they were separate. And that's what 
you're forgetting.

If this is such a point of contention, we can remove the convenience.

> > 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!

It's not looking for its own headers outside. qtsvg is looking for qtbase.

> 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
> ...

The rule is that you remove the development files. You don't have to remove the 
non-development files.

> > 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. 

Yes, it is because it's the same issue.

> > 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.

It's common practice and I am telling you now of it. This practice does not 
come from Qt. It's been there for a long time.

And again: wherever we can implement changes so it is less likely to run into 
this problem, we will. But it's a losing proposition, since there are valid 
cases where there isn't a patch we can implement.

> > 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

Patches are submitted via Gerrit and you know that.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center