[oe] binconfig.bbclass breaks packages QA

[Stanislav Brabec]

Richard Purdie wrote:
> A quick glance at my local build shows 217 .pc files and 14 binconfig
> ones. Of the 14 binconfigs I can spot several that also have .pc files.
> binconfig is being replaced by pkgconfig so this number will only shrink
> with time.

It happens most often with gpg-error-config. It is often embedded to .pc
files, but it has no .pc file. Adding .pc file will not fix the problem,
as configure.in checks for gpg-error-config, not for gpg-error.pc. The
second most problematic is cups-config. Other packages are less often
used, or they have its own .pc file, which is preferred in new projects.
Failed projects are for example libgnomecups, gnumeric.

> Secondly if we wrap gcc that doesn't solve the underlying problem of
> bad .pc files. The neat thing now is that we can move the .pc files
> in/out of a sysroot, onto the target system or into different staging
> directories since there are no hardcoded path problems in them anymore.
> yes we have hardcoded paths in .la files and in the binconfig ones but
> that issue is more manageable than having to hack .pc files as well. 

Imagine situation, where all mangling is removed from all tools and only
gcc will do the mangling internally. foo-config will return
-I/usr/include/foo, pkg-config will embed -I/usr/include/foo, make will
call gcc $CFLAGS -I/usr/include/foo. gcc will search in
sysroot/usr/include/foo and everything should work then.

Looking at gcc Bugzilla, this problem affects all toolchains authors.

Actually, changing OE specific gcc patch to prepend search path with
system path instead of ICE would work-around it as well.

I can imagine small patch doing the same more cleanly:
implement new switches, e. g. --sysroot-all-I --sysroot-all-L.

Then change add_sysroot_to_chain() to mangle all -I paths, not only
those in form -I =.

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus