Bug #2711
closedIncorrect built-in `PKG_CONFIG_PATH` on Ubuntu 32-bit platform
100%
Description
I guess after recent change of waf, the default path where .pc
is installed on Ubuntu 32-bit platform has changed to /usr/local/lib32/pkgconfig
:
We should adjust PKG_CONFIG_PATH
variable set inside wscript. My proposal is just including two additional paths:
- /usr/local/lib32/pkgconfig
- /usr/local/lib64/pkgconfig
Updated by Junxiao Shi over 9 years ago
lib32
appears in waf/Utils.py
which is added in waf:commit:823b4cd2dc03d06a81e0ab003606067da03d8745, but it's "/usr/lib32".
Where does "/usr/local/lib32" come from?
Is /usr/local/lib32/pkgconfig
path in the default search path of pkg-config
?
If not, projects that don't use the "override PKG_CONFIG_PATH
" trick will be affected.
Updated by Alex Afanasyev over 9 years ago
- Status changed from New to Code review
- % Done changed from 0 to 100
Updated by Alex Afanasyev over 9 years ago
The affecting change is in waflib/Tools/gnu_dirs.py
of the same commit. It changes the default value of libdir
from ${EXEC_PREFIX}/lib
to ${EXEC_PREFIX}/lib%s
Updated by Alex Afanasyev over 9 years ago
Is
/usr/local/lib32/pkgconfig
path in the default search path ofpkg-config
?
If not, projects that don't use the "overridePKG_CONFIG_PATH
" trick will be affected.
You cannot ask this question in general. I can say for sure that on Ubuntu 14.04 32-bit and FreeBSD 32-bit, it is not in the default path. If it was in the default path, we wouldn't have the problem.
Updated by Junxiao Shi over 9 years ago
Should we instead patch ndn-cxx's waf to always install to a path that is in default search path of both Ubuntu and OSX?
That would eliminate the need for "override PKG_CONFIG_PATH" trick everywhere.
Updated by Alex Afanasyev over 9 years ago
While I would still suggest we add only "${LIBDIR}/pkgconfig"
to PKG_CONFIG_PATH
(this is exactly the same path libndn-cxx.pc
is installed into), I think there is a bug introduced in waf:commit:823b4cd2dc03d06a81e0ab003606067da03d8745. The condition in Utils.py/lib64 function is very weird...
Updated by Alex Afanasyev over 9 years ago
Unfortunately, I see no viable way to determine "default path" for pkg-config. pkg-config is very "stupid" and doesn't provide such information. You can only guess what is the default and figure out only via checking how it was compiled.
Updated by Junxiao Shi over 9 years ago
I agree with note-6 solution. Please also file a bug with Waf.
By "default search path" I mean a path that is known to work on all our supported platforms.
It can be hardcoded in wscript
, and doesn't need to be determined during configuration/build time.
Updated by Davide Pesavento over 9 years ago
Alex Afanasyev wrote:
The condition in Utils.py/lib64 function is very weird...
The logic they used there can definitely be improved (it's not entirely correct for Gentoo for instance), but I wouldn't say it's very weird.
Updated by Davide Pesavento over 9 years ago
Alex Afanasyev wrote:
Unfortunately, I see no viable way to determine "default path" for pkg-config. pkg-config is very "stupid" and doesn't provide such information. You can only guess what is the default and figure out only via checking how it was compiled.
Nope, not true. You can use pkg-config --variable=pc_path pkg-config
to get the default search path for .pc files.
Updated by Junxiao Shi over 9 years ago
note-6 solution needs verified with MacPorts. Specifically:
- install Boost, CryptoPP, etc with MacPorts
- install ndn-cxx from source code
- compile NFD from source code
Before PKG_CONFIG_PATH
was embedded in wscript
in commit:6db058c4af272c61e465eda9a8116ef207d8349c, OSX builds required manually specifying PKG_CONFIG_PATH=/opt/local/lib/pkgconfig
.
That path is used by MacPorts to install Boost, CryptoPP, etc, but is not included in OSX pkg-config default search path.
In note-6 solution, "${LIBDIR}/pkgconfig"
may not be /opt/local/lib/pkgconfig
, which could prevent OSX pkg-config from finding Boost, CryptoPP, etc.
Updated by Alex Afanasyev over 9 years ago
- Status changed from Code review to Closed
Applied in changeset commit:nfd|cdb8f364c10a7dbfc5b99b6cb1138137f7f999cd.
Updated by Junxiao Shi over 9 years ago
- Related to Bug #2792: Incorrect library install path on Ubuntu 32-bit (and some other 32-bit platforms) added