Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 310807 - sys-devel/crossdev: cross-pkg-config broken PKG_CONFIG_PATH
Summary: sys-devel/crossdev: cross-pkg-config broken PKG_CONFIG_PATH
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-22 23:19 UTC by Piergiorgio Beruto
Modified: 2011-01-24 22:17 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Piergiorgio Beruto 2010-03-22 23:19:31 UTC
the pkg-config wrapper produced by crossdev for any target ignores the PKG_CONFIG_PATH environment variable causing some applications not to compile.

In the crossdev-wrapper script I found this: "Some distribution pollute the pkg-config environment, time to pull a captain planet on them".

Please, note that some applications don't just "pollute" the pkg-config env but actually need the PKG_CONFIG_PATH var. Consider the following scenario:
- autoconf based package with one lib and one program depending on that lib (both autoconf based).
- you don't want to install the application in the filesystem root (in fact I'm cross compiling)
- the lib leaves the mylib.pc and mylib-uninstalled.pc in the installation and build directories respectively.

If the pkg-config ignores the PKG_CONFIG_VAR you'll never able to compiile the above as the program's autoconf fails to find the proper .pc file for the lib.

Thank you.


Reproducible: Always

Steps to Reproduce:
1. set PKG_CONFIG_PATH env var to something containing your .pc files
2. run TARGET-pkg-config --cflags mylib

Actual Results:  
mylib not found

Expected Results:  
cflags declared in mylib.pc for mylib

shoulf NOT ignore the PKG_CONFIG_PATH env var
Comment 1 SpanKY gentoo-dev 2010-03-23 20:38:37 UTC
install your package into the cross-sysroot and everything would work just fine.  the entire point of this crossdev system is to *not* support against a half-assed broken system of a bunch of random build dirs.

PKG_CONFIG_PATH is going to continue to be ignored for the exact reasons quoted in the file comments.  EXTRA_PKG_CONFIG_LIBDIR exists for people who are doing weird stuff like installing their own local packages into their own local tree.  use that.
Comment 2 Piergiorgio Beruto 2010-03-28 10:02:56 UTC
(In reply to comment #1)
> install your package into the cross-sysroot and everything would work just
> fine.  the entire point of this crossdev system is to *not* support against a
> half-assed broken system of a bunch of random build dirs.
> PKG_CONFIG_PATH is going to continue to be ignored for the exact reasons quoted
> in the file comments.  EXTRA_PKG_CONFIG_LIBDIR exists for people who are doing
> weird stuff like installing their own local packages into their own local tree.
>  use that.

I beg your pardon but there are still two problems with this:
1) I don't have root proviledges to install my package in the sysroot, and this is a very common setup for multi user machines as you know.
2) even if I had root priviledges and actually want to install in the sysroot, still some packages wouldn't compile as the pkg-config is needed during the build in the mypackage-uninstalled.pc form (you can find an explanation of the -uninstalled.pc and its purpose in the pkg-config man page).

Also I think there is some misunderstanding... actually I don't need to install my package through crossdev (I guess this is the reason of your answer about not polluting the env), but I just used crossdev to build my own toolchain and then use such toolchain to build my application which is meant to be installed also in users home dir without root priviledges. The problem here is that autoconf will detect the sysrooted pkg-config instead of the host one, which is good but unsets the PKG_CONFIG_PATH.

if the EXTRA_PKG_CONFIG_LIBDIR var (which I don't knew of) can actually be used as a workaound, fine but that's not a good solution for your purpose even if I agree that you shouldn't abuse the PKG_CONFIG_PATH.

Thank you.

Comment 3 SpanKY gentoo-dev 2010-04-11 20:38:15 UTC
plenty of people use Gentoo w/out root -- this is the point of the prefix project.  so not having root isnt terribly relevant, although you must have had root in order to run crossdev in the first place.

name one package that itself sets PKG_CONFIG_PATH in order to compile itself and i can have a look.  otherwise, a package building itself isnt relevant.

i never said you had to "install packages via crossdev".  that statement doesnt even make sense -- `crossdev` is used to build a toolchain only.

otherwise, you still have the option to create your own user-specific root and install/use files out of that.  if that isnt "acceptable", well that's too bad i guess.  there are plenty examples of why PKG_CONFIG_PATH is not usable and must be filtered.  i didnt add the `unset` because i thought it'd be fun.
Comment 4 Piergiorgio Beruto 2010-04-13 12:40:33 UTC
(In reply to comment #3)
> plenty of people use Gentoo w/out root -- this is the point of the prefix
> project.  so not having root isnt terribly relevant, although you must have had
> root in order to run crossdev in the first place.

I tried gentoo prefix actually but unfortunately crossdev jut doesn't work out-of-the-box in prefixed gentoo.

> name one package that itself sets PKG_CONFIG_PATH in order to compile itself
> and i can have a look.  otherwise, a package building itself isnt relevant.
> i never said you had to "install packages via crossdev".  that statement doesnt
> even make sense -- `crossdev` is used to build a toolchain only.

Sorry, I ment using crossdev wrappers over portage. i.e. target-emerge.

> otherwise, you still have the option to create your own user-specific root and
> install/use files out of that.  if that isnt "acceptable", well that's too bad
> i guess.  there are plenty examples of why PKG_CONFIG_PATH is not usable and
> must be filtered.  i didnt add the `unset` because i thought it'd be fun.

I am sure you have good reasons to filter out the PKG_CONFIG_PATH variable, but still I don't understand how you can install a prefixed package without relying on it.

I'll try to explain that better:
- using crossdev I build a powerpc cross-toolchain.
- using that toolchain I cross-compile my library and install it in my own prefixed root (that includes the pkg-config scripts).
- I now want to cross-compile a package that rely on pkg-config to compile against my library. So basically I run configure --prefix=myprefixedroot --host=mycoolpowerpctoolchain. If I don't set the PKG_CONGIH_PATH variable the configure just fails because obviously it can't find my .pc files in the sysroot.

Since the configure now finds the wrapped pkg-config script as expected, It fails to compile because of the PKG_CONFIG_PATH var unset.

I beg your pardon for reopening this bug again but I can't see any work around for that. How would you suggest to solve this problem? 
Comment 5 SpanKY gentoo-dev 2010-04-14 18:20:44 UTC
ive you've installed it into a prefixed root, then using EXTRA_PKG_CONFIG_LIBDIR should work just fine -- set it to the subdir of the prefixed root where the .pc files are being installed
Comment 6 Cyp 2011-01-24 22:17:31 UTC
"Package freetype2 was not found in the pkg-config search path.
Perhaps you should add the directory containing `freetype2.pc'
to the PKG_CONFIG_PATH environment variable"

Is it possible to fix the comment about setting the PKG_CONFIG_PATH variable, since that doesn't seem to do anything, anyway?

Setting EXTRA_PKG_CONFIG_LIBDIR instead didn't seem to work, which I think is due to the "unset EXTRA_PKG_CONFIG_LIBDIR" line.