Bug 251922 - rpmbuild should set PKG_CONFIG_PATH before running %build scriptlet
rpmbuild should set PKG_CONFIG_PATH before running %build scriptlet
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: redhat-rpm-config (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jon Masters
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-13 10:32 EDT by Ray Strode [halfline]
Modified: 2012-11-08 08:16 EST (History)
5 users (show)

See Also:
Fixed In Version: RHBA-2008-0470
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-21 12:51:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ray Strode [halfline] 2007-08-13 10:32:01 EDT
+++ 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@redhat.com 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@redhat.com 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@redhat.com on 2007-01-30 15:59 EST --
Paul, would you be ok with this rpm macros addition ?

-- Additional comment from j.w.r.degoede@hhs.nl 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@redhat.com 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@redhat.com 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@redhat.com 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@mac.com on 2007-02-06 16:36 EST --
This belongs in redhat-rpm-config, not rpm. As does the CLASSPATH ...
Comment 9 errata-xmlrpc 2008-05-21 12:51:33 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2008-0470.html
Comment 10 Chris Ward 2008-06-17 11:48:56 EDT
Reminder: This bug includes the 'RHTS' QA Whiteboard Keyword. Don't forget to add
'RHTSdone' to the QA Whiteboard along with a comment describing where the RHTS
test can be found once the RHTS test has been written. Otherwise, if an RHTS
will not be created, please remove RHTS from the qa whiteboard.

Note You need to log in before you can comment on or make changes to this bug.