|Summary:||rpmbuild should set PKG_CONFIG_PATH before running %build scriptlet|
|Product:||[Fedora] Fedora||Reporter:||Hans de Goede <hdegoede>|
|Component:||rpm||Assignee:||Panu Matilainen <pmatilai>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||mclasen, nobody+pnasrat, pnasrat, rstrode|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-01-15 14:15:56 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
Description Hans de Goede 2006-10-27 08:19:27 UTC
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
Comment 1 Rex Dieter 2007-01-24 13:29:18 UTC
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.
Comment 2 Matthias Clasen 2007-01-30 20:56:31 UTC
Here is a patch to address this without doing multilib violence to further binaries, it all stays confined to the build system...
Comment 3 Matthias Clasen 2007-01-30 20:57:33 UTC
Created attachment 146961 [details] patch to set PKG_CONFIG_PATH in build_pre
Comment 4 Matthias Clasen 2007-01-30 20:59:09 UTC
Paul, would you be ok with this rpm macros addition ?
Comment 5 Hans de Goede 2007-01-31 08:06:59 UTC
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?
Comment 6 Matthias Clasen 2007-01-31 14:44:14 UTC
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.
Comment 7 Matthias Clasen 2007-01-31 14:45:08 UTC
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.
Comment 8 Ray Strode [halfline] 2007-02-06 18:44:42 UTC
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.
Comment 9 Ray Strode [halfline] 2007-02-06 18:47:21 UTC
Comment 10 Jeff Johnson 2007-02-06 21:36:02 UTC
This belongs in redhat-rpm-config, not rpm. As does the CLASSPATH ...
Comment 11 Ray Strode [halfline] 2007-02-06 21:49:30 UTC
Comment 12 Ray Strode [halfline] 2007-04-06 16:19:33 UTC
Any movement on this Jon? It'd be good if we could get this into FC7.
Comment 13 Hans de Goede 2007-07-27 08:13:03 UTC
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!)
Comment 15 Panu Matilainen 2007-08-10 07:00:04 UTC
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...
Comment 17 Panu Matilainen 2008-01-15 14:15:56 UTC
I stuck the patch into rawhide rpm (22.214.171.124-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 ;)