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

[Thiago Macieira]

On Sunday 18 January 2015 23:23:13 René J.V. Bertin wrote:
> > > Is that really different from giving the same instruction to someone
> > > building a new libc version?
> > 
> > No, same instruction.
> 
> 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.

Anyway, this is a recommendation. You may succeed to build with headers in the 
target dir, but if it fails, we can't help you.

> It may be neigh impossible to avoid finding old headerfiles if they're in
> accessible through a standard include path like /usr/include. But that's
> not the case here - which is probably also one of the reasons why the
> -headerdir option exists. A path like /opt/local/include/qt5 (my case) or
> /usr/include/$(DEB_HOST_MULTI_ARCH)/qt5 is *not* in the standard search
> path, and the only time the Qt5 build system should use these paths when
> given through -headerdir is in the install step. (And maybe for configuring
> the qmake copy that will be installed.)

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

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.

> On 12 January 2015 at 17:20, Thiago Macieira <thiago.macieira at intel.com> 
wrote:
> > On Monday 12 January 2015 14:38:20 René J.V. Bertin wrote:
> >> Concerning the error show at  https://paste.kde.org/p2vtxcfcs , it turns
> >> out that it indeed went away after I moved aside /opt/local/include/qt5
> >> . That is the place the headers should go after installation, NOT where
> >> they should be looked for during the build. In other words, `configure
> >> -headerdir foo` should NOT, IMHO, add `-Ifoo` to the
> >> compiler/preprocessor
> >> options!
> >> 
> >> Can that be considered a bug?
> > 
> > Yes.
> 
> I also think that the fact that this header confusion issue exists only with
> qtwebengine (the only component using ninja) means that it is perfectly
> possible to avoid it.

That by itself is not the reason to add -I.

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.

> It should always be "easy". 

Wouldn't we all like it!

> When you're building qtfoo against the system
> qtbase, you will use the system qmake, and you're only going to specify
> headerdirs when you want your qtfoo to be installed elsewhere but system
> wide. But when you're building all of Qt by invoking the toplevel Makefile
> in the build directory (in or out of tree, shouldn't matter, say
> /tmp/qt5build), something else will or should happen. 

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

Now, when you try to compile it with the not-yet-installed qmake, things may 
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.

> - First, a qmake is
> build. It could be a special qmake, or it could be the qmake that will be
> installed later on; that doesn't matter as long as it will use the build
> directory as its QTDIR (QTDIR=/tmp/qt5build). - Then, qtbase is built. It
> remains in place, just like for someone who never does a `make install`. -
> After qtbase, the other components are built in the appropriate order. Each
> of those components is built in the local Qt environment (/tmp/qt5build),
> and the qmake tool from that environment will provide header and library
> paths within that environment.

Patches accepted to implement and verify that it works.

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

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