Bug 212522 - rpmbuild should set PKG_CONFIG_PATH before running %build scriptlet
Summary: rpmbuild should set PKG_CONFIG_PATH before running %build scriptlet
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: multilib
TreeView+ depends on / blocked
 
Reported: 2006-10-27 08:19 UTC by Hans de Goede
Modified: 2008-01-15 14:15 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-01-15 14:15:56 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
patch to set PKG_CONFIG_PATH in build_pre (420 bytes, text/x-patch)
2007-01-30 20:57 UTC, Matthias Clasen
no flags Details

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
retitling, too.

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
okay, moving...

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 (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 ;)


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