Bug 212522
| 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> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | rawhide | CC: | mclasen, nobody+pnasrat, pnasrat, rstrode | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2008-01-15 14:15:56 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 235752 | ||||||
| Attachments: |
|
||||||
|
Description
Hans de Goede
2006-10-27 08:19:27 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. 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 ;) |