[Interest] -headerdir causing headerfile version confusion building qtwebengine (was Qt5 cannot be build on Debian Wheezy? GLIBCXX_3.4.20' not found)

[René J.V. Bertin]

On Monday January 19 2015 09:26:23 Thiago Macieira wrote:
> On Monday 19 January 2015 11:34:43 René J.V. Bertin wrote:


> Hence a recommendation (not a requirement) to build in a clean environment.

It does turn out to be the kind of recommendation one cannot ignore, eh?

> > I'm still a bit surprised though which this isn't an issue with library
> > directories.
> 
> It is.

In what sense? If it's an issue, it's a very subtle one that doesn't cause the build to fail.


> I had already understood the statement and my answer is the same: it's NOT 
> actively looking for it's own headers there. It's looking for qtbase's 
> headers.
> 
> The problem is that it *finds* the old headers, whether it was looking for them 
> or not.

Well, we can let this argument go back and forth a long time still. I don't remember which old headers it actually found, but let me repeat:
> > > OK, it shouldn't be looking for headers of its own version outside of
> > > the parent of its source directory.

Not just its own headers, any header (that should be of the correct version).
In my opinion, adding a non-default -headerdir path to the -I arguments means you're looking there. Of course I never said "it" as looking for old headers, it indeed just happens to find them because it's looking in a place it shouldn't.

> In my opinion, all such systems that build in-place have a serious flaw because 
> you're trusting that software won't accidentally pick up something that is 
> already installed.

Go ahead and change the world if you wish ...

> present. You don't want to deal with a bug report from a user that you can't 
> reproduce because this user has a leftover /usr/local/include/config.h.

Good example, I was looking for that kind of headerfile with a very commonly used name earlier.
How many projects are there that use that header? A majority of those that use autoconf/configure?
And just how often does that lead to issues?
To be honest, I don't know. I do know it's easy enough to debug in this case: /usr/local/include/config.h shouldn't exist, because too common. And most of all, no project should install a file with a name like that in a global include directory.

And speaking about examples: I distinctly recall having encountered projects that have 2 versions of that kind of file (not just headers): one for building itself, and one for installing publicly if there's a need to publish its contents. Python comes to mind.


> 
> Note I wasn't addressing qtwebengine, but a generic problem.

No, but I was, because that's the only place where the issue occurs. I'm most certainly not going off on a hunt for issues that haven't reared their heads yet, but I think I did find the cause for my issue.

qtwebengine/src/core/core_gyp_generator.pro has the following explicit reference to a variable I suppose is controlled by -headerdir :

# something fishy with qmake in 5.2 ?
INCLUDEPATH += $$[QT_INSTALL_HEADERS] $$PWD

I already knew that it is safe to remove the -I/opt/local/include/qt5 instances from the generated ninja files, and when I remove $$[QT_INSTALL_HEADERS] from those ninja files no longer contain the reference. The component is rebuilding now to see if there are side-effects (and who knows, it might even finish tonight...)
If that's the fix for this issue, it's just as easy as I thought it'd be :P

I don't understand the fishy comment though. I don't have a Qt 5.2 source tree around, but qtwebengine is new in 5.4 (no?) and I can't find the term fishy in any .pro files from 5.3.2 ...

R