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
The crux of the problem here is that the pkg-config binary has its default search path hard-wired into the binary, and on multilib systems, only "native" binaries are installed to %_bindir. I'm not sure that adding runtime arch detection is something upstream would be interested in pursuing.
Here is a patch to address this without doing multilib violence to further binaries, it all stays confined to the build system...
Created attachment 146961 [details] patch to set PKG_CONFIG_PATH in build_pre
Paul, would you be ok with this rpm macros addition ?
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?
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.
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.
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.
retitling, too.
This belongs in redhat-rpm-config, not rpm. As does the CLASSPATH ...
okay, moving...
Any movement on this Jon? It'd be good if we could get this into FC7.
Erm, this should be quite easy to fix, or to close as wontfix, so ... PING? Maybe this is something for rpm.org, now that that is fully up and running (great work guys!)
Well I could add it to rpm.org, but that wouldn't really help on Fedora as redhat-rpm-config overrides it. I don't see any reason not to put this in...
I stuck the patch into rawhide rpm (4.4.2.2-13) for now. Optimally it does belong to redhat-rpm-config but we can always move it there later on... (and nothing is as permanent as temporary ;)