[Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)

[Thiago Macieira]

On Sunday 18 January 2015 04:37:50 Kevin Kofler wrote:
> > Moreover, the config files are text, they don't belong in /usr/lib.
> 
> .pc files are text too. They belong into /usr/lib* because they depend on
> the architecture and thus need to be multilibbed, and /usr/lib* is the only
> multilibbed subdirectory of /usr.

And yet they pose problems of the other sort. You solved some problems by 
creating others. For example:

$ pkg-config --cflags dbus-1
-I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include 

There are two problems in this line if I am trying to build a 32-bit program. 
The first is the obvious /usr/lib64. This isn't the common scenario, but there 
are other .pc that may have something arch-dependent in them.

The second and non-obvious one is that it didn't tell me that 
/usr/lib/libdbus-1.so is not present.

So pkg-config should be extended with an "-m32" switch that made it look for 
its sources in /usr/lib/pkgconfig, not in /usr/lib64/pkgconfig. The only way 
around it is to set PKGCONFIG_LIBDIR, as if we were cross-compiling. But if 
we're going to pretend as if we were cross-compiling, bring on the full thing 
and treat it as cross-compilation and skip multilib devel files.

> It would also mean yet one less use case for qtchooser. :-)

Right. That would reduce from 4 to 2 targets you need to support. Since it's 
more than 1, the use-case remains.

> > Until it's complete, using the 64-bit headers for a 32-bit build is also
> > unsupported. Help from distros would be appreciated.
> 
> For headers, we use the "qconfig-multilib.h" hack:
> http://pkgs.fedoraproject.org/cgit/qt5-qtbase.git/tree/qconfig-multilib.h
[snip]

I know.

My complaint is that distros deploy this hack, but none have felt the need to 
upstream a proper solution.

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