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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
