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

[Thiago Macieira]

On Monday 19 January 2015 19:17:51 René J.V. Bertin wrote:
> 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?

YMMV. The problem is really that if it fails, it may fail subtly and you never 
get to find out until you've shipped the binary...

> > > 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'm speaking in generic terms. I don't have any specific case that can cause 
this problem right now.

But the principle is the same: -I flags affect the #include order so you can find 
stale headers and -L flags affect -l flags, so you can find stale libraries.

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

And like I said: it isn't adding the path to -headerdir because you passed it 
to -headerdir. (yes, it is in the qtwebengine case, but I'm talking in 
generic)

It added that because something *else* requested that path. I gave you the 
example of qtsvg searching for QtCore headers, but it could also happen for 
glib header or OpenGL headers or whatever. For example, let's take the case of 
a ports system that puts all the headers in /opt/ports/include so QtCore 
headers end up in /opt/ports/include/QtCore and zlib.h is 
/opt/ports/include/zlib.h.

What might happen is that qtsvg has -I/opt/ports/include so it can find zlib.h 
there, but this -I interferes with the QtCore headers. Worse, this can happen 
for QtCore itself, so QtCore's own build finds its old and stale headers.

A similar thing can happen for libraries: to link to 
/opt/ports/lib/libzlib.dylib, the -L/opt/ports/lib flag interferes with the 
option for -lQt5Core.

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

I don't have to. This is standard practice already. All the major Linux 
distros build their packages like I described. Look at Fedora's Koji or the 
Open Build System or what Debian uses. Take a look at Scratchbox too.

That's also how we build our own binaries at the Qt Project: clean 
configuration, not in someone's machine.

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

I agree with you. My problem is when you as the ports maintainer have to debug 
a problem because this file that shouldn't exist does exist. Preprocessor 
issues are the worst kind, because they often result in very unexpected and 
weird errors, elsewhere. A bad config.h might result in disabled features on an 
otherwise fully-working application, so you'd spend a lot of time debugging to 
find out that it was caused by a left-over build of an unrelated package that 
the user built herself...

Hence, the wish to avoid this error in the first place.

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

Where this occurs *right now*. I'm giving the recommendation because it might 
occur in other places. The recommendation is generic but works for this 
specific case.

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