[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 11:34:43 René J.V. Bertin wrote:
> On Sunday January 18 2015 16:04:27 Thiago Macieira wrote:
> >You are, when you say this:
> I'm sorry, but that really is a misunderstanding.
> 
> >> 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,
> 
>                                                                             
>   ^^^^^^^^^^^^^^^^^^^ That's the key argument.

I understand your argument. But I am saying it's not sufficient because the top-
level build is a collection of independent builds. It's more than a simple 
collection because it tries to do as you ask, but it's still a bunch of 
independent builds.

> >> and thus qtsvg needs to find its headers from the qtbase in that build
> >> directory. NOT in the target.
> >
> >Which in turn means they may behave as if they were separate. And that's
> >what you're forgetting.
> 
> Again, no.
> 
> >If this is such a point of contention, we can remove the convenience.
> 
> If you prefer the easy way out. I still haven't seen definitive proof that
> the issue is unavoidable, something like introducing a circular dependency.
> Or explain (again) why there are use cases in which the -headerdir dir
> *has* to be included in the search path for building certain component(s).

I'm not saying it's unavoidable. I'm saying it's a lot more complex than you 
make it to be, which means there are many scenarios where this fails due to 
the complex inter-dependencies of the modules, external dependencies, etc.

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

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

It is.

> >> 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.
> 
> OK, it shouldn't be looking for headers of its own version outside of the
> parent of its source directory. Is that less ambiguous? 

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.

> (If the libraries are obtained from the appropriate place, there's no reason
> the headers aren't, right?)

The problem is exactly the same.

> >The rule is that you remove the development files. You don't have to remove
> >the non-development files.
> 
> Oh, so there's a subtlety that wasn't mentioned before, development headers
> vs. non development headers? 

There are no non-development headers. All headers are for development, as are 
all .so or .dylib files. However, the library file that contains the full SONAME 
can stay. Just look at how Linux distributions split the regular versus the -
devel packages for libraries.

> Anyway, that's not a rule with clang or gcc (the latter of which I've
> routinely rebuilt using its predecessor for bootstrapping).

Those two are very specific packages that bootstrap themselves, so they have a 
specific requirement that most other packages don't.

> >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.
> 
> Interesting. I've been there a long time too, and have had a lot of
> opportunities to update "system libraries" without going through a
> packaging system. If it's a practice I've somehow only run into it in rare
> exceptions ... that always turned out to be due to a flaw. I think the
> earlier comment from a Gentoo maintainer supports this position. They'd
> taken the practice into account while designing their build system, as
> others with similar approaches would have. I can only speak for MacPorts in
> this context, but that distribution system (based on BSD ports) does not
> provide any way to move aside (parts of) a previous version when building a
> new version. You can do it manually from the file that controls the build,
> but you're on your own to restore everything to its place no matter how the
> actual build terminates. In fact, I think I'm going to bring up the subject
> on their ML ...

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.

A good system is repeatable and isolated. You should always build packages in 
a chroot'ed environment where you control what's present and what's not 
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.

I also speak of this from experience. Two years after its launch, the Yocto 
Project was still finding build issues that were caused by interdependency of 
packages. That is, someone with a faster machine or with more cores would run 
into issues that someone else wouldn't because the build order changed 
slightly.

> >Patches are submitted via Gerrit and you know that.
> 
> Somehow I doubt that a workaround like that stands a chance, esp. if the

Exactly. I asked for a patch, not a workaround like this.

> I'll see what I can come up with without buying an additional machine
> dedicated to running Qt builds. As far as I can tell now it's sadly not a
> simple case where the toplevel Makefile invokes the wrong qmake for
> building qtwebengine, and sadly that module is way down the chain.

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

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