Bug 251922

+++ This bug was initially created as a clone of Bug #212522 +++

I thought that pkgconfig was supposed to get this right and hence it was
used to implement verious replacement foo-config scripts, but pkgconfig
doesn't get this right. When testing I had only libpng-devel.i386
installed not the x86_64 version:
---
[hans@shalem ~]$ pkg-config --cflags libpng
Package libpng was not found in the pkg-config search path.
Perhaps you should add the directory containing `libpng.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libpng' found
---
Behaves as expected, since it searches /usr/lib64/pkgconfig where there
is no libpng.pc
---
[hans@shalem ~]$ setarch i386 pkg-config --cflags libpng
Package libpng was not found in the pkg-config search path.
Perhaps you should add the directory containing `libpng.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libpng' found
[hans@shalem ~]$ ls -l /usr/lib/pkgconfig/libpng.pc
lrwxrwxrwx 1 root root 11 Oct 15 18:50 /usr/lib/pkgconfig/libpng.pc ->
libpng12.pc
---
Does not behave as expected, it should search /usr/lib/pkgconfig and
find libpng.pc

This can be worked around by doing a "export
PKG_CONFIG_PATH=/usr/lib/pkgconfig" when building i386 binaries

-- Additional comment from mclasen on 2007-01-30 15:56 EST --
Here is a patch to address this without doing multilib violence to further
binaries, it all stays confined to the build system...

-- Additional comment from mclasen on 2007-01-30 15:57 EST --
Created an attachment (id=146961)
patch to set PKG_CONFIG_PATH in build_pre


-- Additional comment from mclasen on 2007-01-30 15:59 EST --
Paul, would you be ok with this rpm macros addition ?

-- Additional comment from j.w.r.degoede on 2007-01-31 03:06 EST --
That patch looks like a good solution for rpmbuild, but IMHO has a high bandaid
factor. Has anyone actually tried asking upstream about properly fixing this?


-- Additional comment from mclasen on 2007-01-31 09:44 EST --
Try to write a patch for pkgconfig, and you will see that it would be even more
gross than this workaround. You'll have to take guesses at the value of the
machine field returned by utime. There simply is no sane api for this multilib
business.

-- Additional comment from mclasen on 2007-01-31 09:45 EST --
And if you are doing multilib development using pkgconfig, it is not asking too
much to set PKG_CONFIG_PATH in your build environment, I think.

-- Additional comment from rstrode on 2007-02-06 13:44 EST --
Hi Hans,

Note that almost all of the build tools require explicitly asking which arch to
build for (e.g., -m32).  That may not be the optimal solution, but it's
certainly the most popular one at this point.

pkgconfig's "-m32 flag" is 
export PKG_CONFIG_PATH=/usr/lib/pkgconfig:/usr/share/pkgconfig
 and pkgconfig's "-m64 flag" is
export PKG_CONFIG_PATH=/usr/lib64/pkgconfig:/usr/share/pkgconfig

Just as you must specify the right cflag to gcc to get working multilib, you
have to set the environment variable to the right search path for pkgconfig to 
work with multilib.

Making it guess which path to use based on uname machine type seems error prone
(grep for buildarchtranslate in /usr/lib/rpm/rpmrc to see how out of hand
machine type mappings can get).  Until there is a nicer api to say "magically
give me the right libdir" this is really the best way to go.

Reassigning to rpm.

-- Additional comment from n3npq on 2007-02-06 16:36 EST --
This belongs in redhat-rpm-config, not rpm. As does the CLASSPATH ...