rust-lang / pkg-config-rs Goto Github PK

View Code? Open in Web Editor NEW

165.0 10.0 80.0 978 KB

Build library for invoking pkg-config for Rust

Home Page: https://docs.rs/pkg-config

License: Apache License 2.0

Rust 100.00%

pkg-config-rs's Introduction

pkg-config-rs

Documentation

A simple library meant to be used as a build dependency with Cargo packages in order to use the system pkg-config tool (if available) to determine where a library is located.

You can use this crate directly to probe for specific libraries, or use system-deps to declare all your pkg-config dependencies in Cargo.toml.

This library requires Rust 1.30+.

Example

Find the system library named foo, with minimum version 1.2.3:

extern crate pkg_config;

fn main() {
    pkg_config::Config::new().atleast_version("1.2.3").probe("foo").unwrap();
}

Find the system library named foo, with no version requirement (not recommended):

extern crate pkg_config;

fn main() {
    pkg_config::probe_library("foo").unwrap();
}

External configuration via target-scoped environment variables

In cross-compilation context, it is useful to manage separately PKG_CONFIG_PATH and a few other variables for the host and the target platform.

The supported variables are: PKG_CONFIG_PATH, PKG_CONFIG_LIBDIR, and PKG_CONFIG_SYSROOT_DIR.

Each of these variables can also be supplied with certain prefixes and suffixes, in the following prioritized order:

<var>_<target> - for example, PKG_CONFIG_PATH_x86_64-unknown-linux-gnu
<var>_<target_with_underscores> - for example, PKG_CONFIG_PATH_x86_64_unknown_linux_gnu
<build-kind>_<var> - for example, HOST_PKG_CONFIG_PATH or TARGET_PKG_CONFIG_PATH
<var> - a plain PKG_CONFIG_PATH

This crate will allow pkg-config to be used in cross-compilation if PKG_CONFIG_SYSROOT_DIR or PKG_CONFIG is set. You can set PKG_CONFIG_ALLOW_CROSS=1 to bypass the compatibility check, but please note that enabling use of pkg-config in cross-compilation without appropriate sysroot and search paths set is likely to break builds.

Some Rust sys crates support building vendored libraries from source, which may be a work around for lack of cross-compilation support in pkg-config.

License

This project is licensed under either of

Apache License, Version 2.0, (LICENSE-APACHE or https://www.apache.org/licenses/LICENSE-2.0)
MIT license (LICENSE-MIT or https://opensource.org/licenses/MIT)

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in pkg-config-rs by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

pkg-config-rs's People

Contributors

Stargazers

Watchers

pkg-config-rs's Issues

Dependencies on the environment variables are not properly reported to cargo

Changing PKG_CONFIG_PATH and rebuilding some crate that depends on the pkg_config crate (directly or indirectly) will not rebuild the crates that pull their dependencies from pkg-config.

[Feature request] Provide a way to bypass pkg-config's logic by providing minimal info via env

Primary idea behind this feature request is that currenty build.rs script has to duplicate some logic and data structure if FOO_NO_PKG_CONFIG is passed or no pkg-config is available on target system.

E.g. if I have FOO_LIB_PATH and FOO_INC_PATH for override in my build.rs I will have a struct which stores include_paths: Vec<PathBuf> and link_paths: Vec<PathBuf> (at least) which is populated from something like

let link_paths: Vec<_> = env::var_os("FOO_LIB_PATH")
    .map(|ps| { env::split_paths(&ps).collect() })
    .or_else(Vec::with_capacity(0));
let include_paths: Vec<_> = ...;

and have to emit cargo:rustc-link-lib=... and cargo:rustc-link-search=native=... afterwards like pkg-config crate does.

If such feature is implemeted build.rs would be much simplier for such simple cases.

Would you accept PR for this or my idea has some fatal flaws which could prevent this?

Provide the version number

I’m wondering if it could be a useful feature to provide the version number of the requested library (if found), that is, to provide the output of pkg-config --modversion. I have a use case for that, but I’m not sure if it’s of general interest. For instance, one could imagine enabling/disabling certain features depending on the available version. Thank you.

Regards,
Ivan

Support, Query multiple libraries at once.

I was able to achieve this with the arg() fn.

Provide something to perform include directory lookups

It's sometimes necessary to write gross C shims to deal with libraries, and it'd be nice for pkg-query to be able to pull the include paths for gcc-rs.

https://github.com/sfackler/rust-openssl/blob/master/openssl-sys/src/old_openssl_shim.c
https://github.com/sfackler/rust-openssl/blob/6ef819f9718c3b43551461b72c531c2eeee878f9/openssl-sys/build.rs#L39-L50

Bug: `is_system` erroneously reports that a library is a system library in some cases.

The is_system function uses a heuristic "path starts with /usr" to check whether a library is a system library. For reasons unknown to me, being a system library blocks static linking.

The function iterates all the dirs and checks if any of them is a non-system library. If even one library search path is found for the library that is "non-system", the function returns false. If all the search paths are system libraries, the function returns true.

However, the function has a bug: if the list of search dirs passed to it is empty, the function returns true. I'm not sure how should it behave if the list is empty, but certainly returning "this is a system lib" when the library is actually not, is wrong behaviour.

There's some other concerns too: the dirs are added to the list in the order they are got from pkg-config. This is the reason the dir list may be empty in the first place; pkg-config might return something like: -I/musl/include -lssl -lcrypto -L/musl/lib -ldl.

There's another concern too. That has more to do with the spirit of this issue I posted just a moment ago in the Rust repo: rust-lang/rust#39998 If the pkg-config knows that I want to link statically (after all, I specified the env vars!), why does it silently pass dynamic flags to cargo instead of erroring: "You said you want to link statically but what you've got here is a system lib, I can't link that statically!"

Using pkg-config in build.rs on FreeBSD brokes ncurses normal work

Consider the following program:

#![feature(extern_types)]

use libc::{LC_ALL, setlocale, c_int, c_char};

extern "C" {
    pub type WINDOW;
    pub fn initscr() -> *mut WINDOW;
    pub fn cbreak() -> c_int;
    pub fn noecho() -> c_int;
    pub fn keypad(arg1: *mut WINDOW, arg2: bool) -> c_int;
    pub static mut stdscr: *mut WINDOW;
    pub fn clear() -> c_int;
    #[link_name = "\u{1}move"]
    pub fn move_(arg1: c_int, arg2: c_int) -> c_int;
    pub fn insnstr(arg1: *const c_char, arg2: c_int) -> c_int;
    pub fn getch() -> c_int;
    pub fn endwin() -> c_int;
    pub fn addnstr(arg1: *const c_char, arg2: c_int,) -> c_int;
}

fn main() {
    unsafe {
        setlocale(LC_ALL, b"\0".as_ptr() as _);
        initscr();
        cbreak(); 
        noecho(); 
        keypad(stdscr, true);
        clear();
        let s = "x\0";
        let t = "Привет\0";
        move_(10, 10);
        addnstr(s.as_ptr() as _, 1);
        move_(10, 10);
        insnstr(t.as_ptr() as _, 2);
        getch();
        endwin();
    }
}

with the following build.rs:

fn main() {
    println!("cargo:rerun-if-env-changed=PKG_CONFIG_PATH");
//    pkg_config::Config::new()
//        .atleast_version("5.0")
//        .probe("ncursesw")
//        .unwrap();
    println!("cargo:rustc-link-lib=ncursesw");
}

After running It works correctly and prints "Пx" as expected (consider this stackoverflow answer if you have doubts about expected ncurses behavior).

Now, uncomment pkg_config in build.rs. With uncommented pkg_config program behaves differently and prints "Прx" instead of "Пx".

I believe, pkg_config should not alter program behavior in this situation.

Add support for MSVC

See here. In theory this should work by just passing --msvc-syntax to pkg-config.

Install/build pkg-config if it's not available on the system

Shouldn't be too hard via the cc crate and downloading it in build.rs.

Suggestion: follow symlinks to save the macOS use-case

It's common to install libraries with Homebrew on macOS. However, when linking those libraries with the pkg-config crate, the -L/usr/local/lib flag is passed to Cargo. This may cause conflicts with dynamic resolution: /usr/local/lib gets always searched first, and unrelated libraries may override system libraries causing havoc.

An example: dynamically loaded libjpeg is a transitive dependency of Diesel. However, an incompatible version of libjpeg is also commonly installed to /usr/local/lib as a dependency of some Homebrew application. A dependency of Diesel, libpq used to support finding the native library using the pkg-config crate, but since that passes -L/usr/local/lib to Cargo which breaks libjpeg, the support had to be revoked.

libpq itself now avoids passing /usr/local/lib to Cargo, and instead checks if the library is actually a symlink. In the case of Homebrew, it always is; every library resides in their own directories, like /usr/local/Cellar/jpeg/8d/lib/. Thus, passing that to Cargo doesn't cause conflicts with other libraries.

To be usable in the macOS ecosystem, it would be beneficial if the pkg-config crate would provide this symlink-following behaviour for the users.

Travis CI badge points to wrong url

It should be

pkg-config-rs does not find library, but pkg-config does

I want to build my crate (which depends on dbus) in a Travis CI environment.
Inside the environment I install libdbus-1-dev [1] but for some reason I have to set the PKG_CONFIG_PATH environment variable [2]. If I do this, pkg-config works fine for the dbus library [3].
However, rust is not able to find the dbus library [4] and fails to compile the dbus crate.

I am wondering why this happens. Could it be that the pkg-config-rs crate somehow does not pass PKG_CONFIG_PATH to pkg-config (although I exported the environment variable)?

[1] https://travis-ci.org/manuels/bulletinboard-dht/jobs/218511540#L326
[2] https://travis-ci.org/manuels/bulletinboard-dht/jobs/218511540#L352
[3] https://travis-ci.org/manuels/bulletinboard-dht/jobs/218511540#L418
[4] https://travis-ci.org/manuels/bulletinboard-dht/jobs/218511540#L486

PKG_CONFIG_ALLOW_SYSTEM_CFLAGS and cross-compiling

Hi!

I recently ran into a very strange cross-compiling issue and tracked it down to the changes in #93. My crate depends on other crates which use pkg-config to locate system libraries. Things are all well and good in the native build environment, however having this flag enabled by default is causing me grief when cross-compiling.

My linker is not too keen on having /usr/include passed along as an include folder:

cargo:warning=arm-buildroot-linux-gnueabihf-gcc: ERROR: unsafe header/library path used in cross-compilation: '-I' '/usr/include'

The changelog says that PGK_CONFIG_ALLOW_SYSTEM_CFLAGS is enabled by default, so I'm assuming that means there is a way to disable it.

My question - Can I disable this via configuration in Cargo.toml?
I don't have direct access to the crates which are actually using pkg-config for library location.

Currently I'm just pinning this crate to 0.3.15 in one of my Cargo.toml files so that 0.3.16 is not used.

Version checking is broken

The command line parameters used to check for a minimal library version are not actually legal:

% pkg-config --libs --atleast-version="0.21.0" libgit2
Ignoring incompatible output option "--atleast-version"
-lgit2

One possible fix would be to rewrite the call to:

% pkg-config --libs "libgit2 >= 0.21.0"
-lgit2

Alternatively a separate function could be provided, to check for a libraries existence.

rustc 1.14.0 complains about "#![feature(path)]" error[E0554]: #[feature] may not be used on the stable release channel

I'm trying to package rust-pkg-config (ha!) for the GNU Guix distribution but I get the following error message (using rustc 1.14.0):

error[E0554]: #[feature] may not be used on the stable release channel

What should I do?

Undefined references when linking with poppler on Ubuntu 17.10

When I run cargo build on attached sample rust program test.zip I am getting undefined references:

In function `test':
          /home/miso/test/test.c:6: undefined reference to `g_get_current_dir'
          /home/miso/test/test.c:7: undefined reference to `g_build_filename'
          /home/miso/test/test.c:8: undefined reference to `g_filename_to_uri'

Dependencies are from these ubuntu packages: libpoppler-glib-dev libcairo2-dev libpango1.0-dev

It is working for example on OSX but on both I am getting these warnings:

warning: redundant linker flag specified for library `cairo`
warning: redundant linker flag specified for library `gobject-2.0`
warning: redundant linker flag specified for library `glib-2.0`

These warnings are probably because pkg-config is not checking whether emitting duplicated dependencies from multiple packages into stdout:

cargo:rustc-link-search=native=/usr/lib/x86_64-linux-gnu
cargo:rustc-link-lib=poppler-glib
cargo:rustc-link-lib=gio-2.0
cargo:rustc-link-lib=gobject-2.0
cargo:rustc-link-lib=glib-2.0
cargo:rustc-link-lib=cairo
cargo:rustc-link-search=native=/usr/lib/x86_64-linux-gnu
cargo:rustc-link-lib=cairo
cargo:rustc-link-search=native=/usr/lib/x86_64-linux-gnu
cargo:rustc-link-lib=pangocairo-1.0
cargo:rustc-link-lib=pango-1.0
cargo:rustc-link-lib=gobject-2.0
cargo:rustc-link-lib=glib-2.0
cargo:rustc-link-lib=cairo

Here is output from terminal from cargo build -v on Ubuntu:

     Running `/home/miso/test/target/debug/build/test-9b662f66ec35ba4e/build-script-build`
     Running `rustc --crate-name test test.rs --crate-type bin --emit=dep-info,link -C debuginfo=2 -C metadata=fe9134e5c08aec2d -C extra-filename=-fe9134e5c08aec2d --out-dir /home/miso/test/target/debug/deps -C incremental=/home/miso/test/target/debug/incremental -L dependency=/home/miso/test/target/debug/deps -L native=/usr/lib/x86_64-linux-gnu -L native=/usr/lib/x86_64-linux-gnu -L native=/usr/lib/x86_64-linux-gnu -L native=/home/miso/test/target/debug/build/test-201ba572ee26061f/out -l poppler-glib -l gio-2.0 -l gobject-2.0 -l glib-2.0 -l cairo -l cairo -l pangocairo-1.0 -l pango-1.0 -l gobject-2.0 -l glib-2.0 -l cairo -l static=test`
warning: redundant linker flag specified for library `cairo`

warning: redundant linker flag specified for library `gobject-2.0`

warning: redundant linker flag specified for library `glib-2.0`

error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/miso/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/miso/test/target/debug/deps/test-fe9134e5c08aec2d.1y16o1qfye96o7m0.rcgu.o" "/home/miso/test/target/debug/deps/test-fe9134e5c08aec2d.3rngp6bm2u2q5z0y.rcgu.o" "/home/miso/test/target/debug/deps/test-fe9134e5c08aec2d.4oc10dk278mpk1vy.rcgu.o" "/home/miso/test/target/debug/deps/test-fe9134e5c08aec2d.oa3rad818d8sgn4.rcgu.o" "/home/miso/test/target/debug/deps/test-fe9134e5c08aec2d.z2ztxthfpf83dor.rcgu.o" "-o" "/home/miso/test/target/debug/deps/test-fe9134e5c08aec2d" "/home/miso/test/target/debug/deps/test-fe9134e5c08aec2d.crate.allocator.rcgu.o" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs" "-L" "/home/miso/test/target/debug/deps" "-L" "/usr/lib/x86_64-linux-gnu" "-L" "/usr/lib/x86_64-linux-gnu" "-L" "/usr/lib/x86_64-linux-gnu" "-L" "/home/miso/test/target/debug/build/test-201ba572ee26061f/out" "-L" "/home/miso/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-l" "poppler-glib" "-l" "gio-2.0" "-l" "gobject-2.0" "-l" "glib-2.0" "-l" "cairo" "-l" "pangocairo-1.0" "-l" "pango-1.0" "-Wl,-Bstatic" "-Wl,--whole-archive" "-l" "test" "-Wl,--no-whole-archive" "-Wl,--start-group" "/home/miso/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-0888da25bc5aa659.rlib" "/home/miso/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-c21a3f7e9b2ce71d.rlib" "/home/miso/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-a89ec74248f6f925.rlib" "/home/miso/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-9232e45013d81e94.rlib" "/home/miso/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_system-afbe0a28ca4ea99f.rlib" "/home/miso/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-bcf95ff3aa4e3276.rlib" "/home/miso/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-26716181a02171e3.rlib" "/home/miso/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-978afee7e21437ec.rlib" "-Wl,--end-group" "/home/miso/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-3f4ad009a7cf735f.rlib" "-Wl,-Bdynamic" "-l" "dl" "-l" "rt" "-l" "pthread" "-l" "pthread" "-l" "gcc_s" "-l" "c" "-l" "m" "-l" "rt" "-l" "pthread" "-l" "util" "-l" "util"
  = note: /home/miso/test/target/debug/build/test-201ba572ee26061f/out/libtest.a(test.o): In function `test':
          /home/miso/test/test.c:6: undefined reference to `g_get_current_dir'
          /home/miso/test/test.c:7: undefined reference to `g_build_filename'
          /home/miso/test/test.c:8: undefined reference to `g_filename_to_uri'
          /home/miso/test/test.c:9: undefined reference to `poppler_document_new_from_file'
          /home/miso/test/test.c:11: undefined reference to `poppler_document_get_n_pages'
          /home/miso/test/test.c:13: undefined reference to `g_object_unref'
          /home/miso/test/test.c:14: undefined reference to `g_free'
          /home/miso/test/test.c:15: undefined reference to `g_free'
          /home/miso/test/test.c:16: undefined reference to `g_free'
          collect2: error: ld returned 1 exit status
          

error: aborting due to previous error

error: Could not compile `test`.

Caused by:
  process didn't exit successfully: `rustc --crate-name test test.rs --crate-type bin --emit=dep-info,link -C debuginfo=2 -C metadata=fe9134e5c08aec2d -C extra-filename=-fe9134e5c08aec2d --out-dir /home/miso/test/target/debug/deps -C incremental=/home/miso/test/target/debug/incremental -L dependency=/home/miso/test/target/debug/deps -L native=/usr/lib/x86_64-linux-gnu -L native=/usr/lib/x86_64-linux-gnu -L native=/usr/lib/x86_64-linux-gnu -L native=/home/miso/test/target/debug/build/test-201ba572ee26061f/out -l poppler-glib -l gio-2.0 -l gobject-2.0 -l glib-2.0 -l cairo -l cairo -l pangocairo-1.0 -l pango-1.0 -l gobject-2.0 -l glib-2.0 -l cairo -l static=test` (exit code: 101)

Rust version stable 1.27.1.

When I try to emit dependencies manually into stdout then it is compiling without problems.

spelling mistake

pkg_config::Config::statik should be pkg_config::Config::static

...unless this is deliberate, for some reason?

statik(true) doesn't do anything on macOS

In macOS passing --static to pkg-config is not enough to get the library linked statically. For almost all packages both .a and .dylib exist, and names specified by pkg-config are ambiguous.

$ pkg-config --static --libs lcms2
-L/usr/local/Cellar/little-cms2/2.8/lib -llcms2 -lm
$ pkg-config --libs lcms2
-L/usr/local/Cellar/little-cms2/2.8/lib -llcms2

Instructions printed by pkg-config don't specify that static linking was requested:

cargo:rustc-link-search=native=/usr/local/Cellar/little-cms2/2.8/lib
cargo:rustc-link-lib=lcms2
cargo:rustc-link-lib=m

So rustc invocation switches to dynamic linking:

Running rustc … -l z -l lcms2 -l m…

otool -L target/release/test
    /usr/local/opt/little-cms2/lib/liblcms2.2.dylib (compatibility version 3.0.0, current version 3.8.0)

I think this library should be printing rustc-link-lib=static=lcms2 when .statik(true) was specified (but only for the probed library, e.g. don't statically link libz if libpng was probed)

Library::version can return multiple lines

When using version number restrictions (such as atleast_version), the resulting pkg-config command will return the version number multiple times on different lines. For example, I have the following in my code:

    let libuv = pkg_config::Config::new()
        .range_version("1.30".."1.31")
        .probe("libuv");

Which results in something like the following getting run:

$ pkg-config --modversion libuv 'libuv >= 1.30' 'libuv < 1.31'
1.30.1
1.30.1
1.30.1

So libuv.version ends up being a string with the version repeated three times on different lines.

Support exact_version

pkg-config provides name = version syntax to specify the exact version. It would be nice to add a wrapper for this functionality. Although pkg_config::probe_library("name = version") works, I think it is abuse.

Backslashes in pkg-config output are processed incorrectly

pkg-config uses backslash to preserve literal meaning of following byte.
Different arguments are separated by unescaped space. The idea behind all this,
is to be compatible with parsing behaviour of UNIX shell, when used in
following manner from a makefile:

program: program.c
     cc program.c $(shell pkg-config --cflags --libs ..)

That doesn't actually work in full generality, because in UNIX shell backslash
escaping works character wise, and pkg-config does escape everything outside
ASCII, but in byte wise manner. Just remember not to put emoji in header
include directories and you will be fine.

EDIT:

Once fixed, this part should no longer be necessary: https://github.com/alexcrichton/pkg-config-rs/blob/5203aff8b20479c9df159be2efb4162450019330/src/lib.rs#L507

EDIT 2: Previous example, was broken.

Linkage of static library from `/usr/lib64` ignored with `-L` flag warning

Using fedora 27, openssl-static provides /usr/lib64/libssl.so and /usr/lib64/libcrypto.so.

The below commit prevents this from linking properly.

9a57960

Expectation: If I set OPENSSL_STATIC I'd either expect the whole thing to fail, print a very descriptive warning with a hint on how to fix this.
What happens actually: a) Missing -L flag warning, b) links dynamically (which I explicitly want to prevent (need to share this from Ubuntu 16.04 over Arch to Fedora Rawhide)

I also opend a topic: https://users.rust-lang.org/t/how-to-link-openssl-statically/14912/2
Also filed: sfackler/rust-openssl#825 (comment)
Possibly related: #37

Yank all broken pkg-config versions from crates.io

On https://crates.io/crates/pkg-config/versions everything below v0.3.2 does not compile with recent Rust versions. They should all be yanked so that cargo only installs working minimal versions.

Static linking is too restrictive

pkg-config-rs/src/lib.rs

Lines 570 to 581 in ef356f3

 fn is_static_available(name: &str, dirs: &[PathBuf]) -> bool { 

 let libname = format!("lib{}.a", name); 

 let system_roots = if cfg!(target_os = "macos") { 

 vec![Path::new("/Library"), Path::new("/System")] 

 } else { 

 vec![Path::new("/usr")] 

 }; 

 dirs.iter().any(|dir| { 

 !system_roots.iter().any(|sys| dir.starts_with(sys)) && dir.join(&libname).exists() 

 }) 

 }

Basically any library which falls into /usr/lib/ won't be statically linked (which is basically all libraries found by pkg-config). Why is this logic there?

Unable to compile pkg-config on Ubuntu 18 LTS x64

I have a test project with blurz 0.4.0 as its sole dependency. The dependency tree looks like this:

hello_world v0.1.0 (/home/josh/VirtualShare/rust_test_2)
└── blurz v0.4.0
    ├── dbus v0.6.4
    │   ├── libc v0.2.58
    │   └── libdbus-sys v0.1.5
    │       [build-dependencies]
    │       └── pkg-config v0.3.14
    └── hex v0.3.2

Running 'cargo build' fails with a very opaque error:

josh@dev:~/VirtualShare/rust_test_2$ cargo build -v
   Compiling pkg-config v0.3.14
     Running `rustc --crate-name pkg_config /home/josh/.cargo/registry/src/github.com-1ecc6299db9ec823/pkg-config-0.3.14/src/lib.rs --color always --crate-type lib --emit=dep-info,metadata,link -C debuginfo=2 -C metadata=d60f45c28fbc45a5 -C extra-filename=-d60f45c28fbc45a5 --out-dir /home/josh/VirtualShare/rust_test_2/target/debug/deps -L dependency=/home/josh/VirtualShare/rust_test_2/target/debug/deps --cap-lints allow`
error: Operation not permitted (os error 1)

Any help here would be appreciated.

error: can't find crate for `pkg_config`

Looks like there is a bug in with the lastest version of pkg-config. I'm using rustc 1.0.0-nightly (123a754cb 2015-03-24) (built 2015-03-25) and running cargo test raises an error:

$ git clone https://github.com/alexcrichton/pkg-config-rs.git
$ cd pkg-config-rs
$ cargo build # works fine
   Compiling pkg-config v0.3.2 (file:///tmp/pkg-config-rs)
$ cargo test # fails
   Compiling pkg-config v0.3.2 (file:///tmp/pkg-config-rs)
tests/disabled.rs:3:14: 3:26 warning: obsolete syntax: "crate-name"
tests/disabled.rs:3 extern crate "pkg-config" as pkg_config;
                                 ^~~~~~~~~~~~
note: use an identifier not in quotes instead
tests/disabled.rs:3:1: 3:41 warning: crate names soon cannot contain hyphens: pkg-config
tests/disabled.rs:3 extern crate "pkg-config" as pkg_config;
                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
tests/disabled.rs:3:1: 3:41 error: can't find crate for `pkg_config`
tests/disabled.rs:3 extern crate "pkg-config" as pkg_config;
                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error
Could not compile `pkg-config`.

To learn more, run the command again with --verbose.

Do you have a clue what's going on here? This error is also raised for any crates depending on pkg-config.

Specify minimal required Rust version

The pkg-config 0.3.10 update broke downstream crates on Rust 1.21...

error[E0599]: no method named `to_ascii_uppercase` found for type `char` in the current scope
   --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/pkg-config-0.3.10/src/lib.rs:538:28
    |
538 |     name.chars().map(|c| c.to_ascii_uppercase()).map(|c| {
    |                            ^^^^^^^^^^^^^^^^^^
    |
    = help: items from traits can only be used if the trait is in scope
    = note: the following trait is implemented but not in scope, perhaps add a `use` for it:
            candidate #1: `use std::ascii::AsciiExt;`

I run cargo-audit in CI for most of my crates, which depends on pkg-config (directly or indirectly). Unfortunately this means that I cannot use cargo-audit in CI for crates supporting Rust 1.21 without adding a separate build step that runs on a newer version.

Would it be possible to specify the minimal required Rust version, to add that version to CI and to consider changes to the minimal version a breaking change?

Allow pkg-config checks to be skipped in CI environments that don't use or care about linking

I have a project with a dependency which uses pkg-config. The dependency's build script matches your suggestion in the readme:

fn main() {
    pkg_config::probe_library("somelibrary").unwrap();
}

I am running tests with Travis CI using their docker infrastructure. I have ensured the dependency and executable pkg-config are installed in the container.
However, when compiling my project the CI builds fail because pkg-config can't find the library this dependency requests. The pkg-config crate-level docs suggest setting $FOO_NO_PKG_CONFIG but this will just fail the builds "faster" as the unwrap() will still panic.

I could file an issue with this dependency, or look into installing pkg-config on Travis, or file an issue about supporting Travis CI specifically. However, given the existence of the *_NO_PKG_CONFIG I figured you wouldn't be opposed to *_SKIP_PKG_CONFIG, which would be more fine-grained - I am using the workaround export PKG_CONFIG=echo (which is also not in the documentation) to prevent pkg-config from running at all in the CI environment.

Let me know what you think and I can open a PR.

If PKG_CONFIG is already overriden then default PKG_CONFIG_ALLOW_CROSS to yes

I've been trying to cross-compile cargo and although I've succeeded now, I ran into several cases where I had to set random environment variables for it to work. Here, PKG_CONFIG_ALLOW_CROSS seems a bit unnecessary, if PKG_CONFIG is already overriden then probably the user/builder knows what they're doing and there is no need to put artificial guards in that make the process Just Not Work.

please use PKG_CONFIG_KEEP_SYSTEM_CFLAGS and PKG_CONFIG_KEEP_SYSTEM_LIBS

The rust pkg_config crate parses the gcc cflags and link flag output of pkg-config to deduce semantic meaning behind certain flags.

There's nothing wrong with that per se, but pkgconf typically assumes that when invoked, it is generating output for use with the system C/C++ compiler. Accordingly, it typically simplifies the output it generates for the convenience of humans using the tool by removing flags that gcc automatically implies (such as -I/usr/include for example).

This causes strange conflicts with the pkg_config crate naturally. This can be fixed by telling pkgconf that you're not GCC, by adding two environment variables:

PKG_CONFIG_SYSTEM_INCLUDE_PATH=
PKG_CONFIG_SYSTEM_LIBRARY_PATH=

These paths should be either blank or paths that will automatically be implied by the toolchain. In the case of rust-onig/rust-onig#119, the paths should be blank if the implied paths (e.g. /usr/include) will not be included in the include_paths property.

Including system library paths makes it difficult to overide library versions

At present, Config::find returns system library paths. This can make it difficult to override library versions.

The motiviating example is using rust-openssl with ssh2-rs on OS X. On Mac, openssl requires a non-system version of openssl for TLS support, which can successfuly be provided by homebrew, for example. ssh2-rs depends on libz-rs, which pkg-config finds as -L /usr/lib. This library path gets added before the openssl library path, resulting in the system (older) openssl libraries being used, and the linker failing.

[Feature request] Support $TARGET-pkg-config for cross-compilation

My Debian system has following scripts in /usr/bin:

i686-linux-gnu-pkg-config
i686-w64-mingw32-pkg-config
pkg-config
x86_64-linux-gnu-pkg-config
x86_64-linux-gnux32-pkg-config
x86_64-pc-linux-gnu-pkg-config
x86_64-w64-mingw32-pkg-config

The prefixed scripts are symlinks to a wrapper that sets PKG_CONFIG_LIBDIR to the appropriate multilib directory to point to the correct package architecture. Since that is how libraries for cross-compilation toolchains are normally installed, it should work out of the box with them.

So I'd like to suggest to:

If $TARGET != $HOST, look for $TARGET-pkg-config and $GCC_TARGET-pkg-config script instead of pkg-config and
If it exists, the target_supported() function should return true and the script would be called.

The mapping from llvm-style $TARGET and gcc-style $GCC_TARGET is unfortunately not uniform, but looking at the list of targets both Rust and Debian know, two replacement rules should be sufficient:

1.-unknown- → - and
2. -pc-windows-gnu → -w64-mingw32

The scripts seem to be created when multi-arch is enabled for given target (with mingw/windows being a special case) and I only have that for amd64 (native), i386 and x32, but I believe these days it should work for qemu-emulated architectures too, so somebody can conceivably have arm-linux-gnueabi-pkg-config or aarch64-linux-gnu-pkg-config and if they do, it is going to work with the corresponding prefixed gcc linker.

(The curious x86_64-pc-linux-gnu-pkg-config is strangely a plain hardlink to pkg-config though the default gcc target is as expected just x86_64-linux-gnu with no -pc-; I believe it can be safely ignored)

Accept '-F' and '-framework' flags

For OS X -F and -framework flags need to be accepted and translated into into -L framework=... and -l framework=..., respectively.

The -F option needs to be added to rustc before, see rust-lang/rust/#20259.

pkg-config finds mingw *.a library for msvc target

Found this because on my windows msvc target, cargo install rustup-toolchain-install-master finds msys2's liblzma.a, converts the name to lzma.lib which is non-existant file, and tries to compile which gives error during linking.

Library should derive Clone, Copy, and likely Debug.

I wrote a fn to call probe(), but this causes pkg_config to be run multiple times and I'm concerned about getting different results from each run.

pkg-config fails to find cairo.pc and glib-2.0.pc on MSYS2 Win64

I am trying to build a simple GTK test app on Win64 (using MSYS). When I try to build it, the following happens:

Sam@sam-laptop MSYS /d/dev/Rust/src/gtk_test
$ cargo build
   Compiling glib-sys v0.3.0
   Compiling cairo-sys-rs v0.3.0
Build failed, waiting for other jobs to finish...
failed to run custom build command for `cairo-sys-rs v0.3.0`
Process didn't exit successfully: `D:\dev\Rust\src\gtk_test\target\debug\build\cairo-sys-rs-45a32580d0558aa8\build-script-build` (exit code: 1)
--- stderr
`"pkg-config" "--libs" "--cflags" "cairo >= 1.10"` did not exit successfully: exit code: 1
--- stdout
Package cairo was not found in the pkg-config search path.
Perhaps you should add the directory containing `cairo.pc'
to the PKG_CONFIG_PATH environment variable
No package 'cairo' found

I noticed that pkg-config was failing to find either cairo.pc or glib-2.0.pc. I found the files it was missing in the $PKG_CONFIG_PATH, so I tried running the same pkg-config call it says it is running, and it seems to run fine without errors.

Sam@sam-laptop MSYS /d/dev/Rust/src/gtk_test
$ echo $PKG_CONFIG_PATH
/usr/lib/pkgconfig:/usr/share/pkgconfig:/lib/pkgconfig:/mingw64/lib/pkgconfig

Sam@sam-laptop MSYS /d/dev/Rust/src/gtk_test
$ find /mingw64 -name cairo.pc
/mingw64/lib/pkgconfig/cairo.pc

Sam@sam-laptop MSYS /d/dev/Rust/src/gtk_test
$ find /mingw64 -name glib-2.0.pc
/mingw64/lib/pkgconfig/glib-2.0.pc

Sam@sam-laptop MSYS /d/dev/Rust/src/gtk_test
$ pkg-config --libs --cflags "cairo >= 1.10"
-mms-bitfields -I/mingw64/include/cairo -I/mingw64/include/pixman-1 -I/mingw64/include -I/mingw64/include/freetype2 -I/mingw64/include/libpng16 -I/mingw64/include/harfbuzz -I/mingw64/include/glib-2.0 -I/mingw64/lib/glib-2.0/include -I/mingw64/include -I/mingw64/include/freetype2 -I/mingw64/include -I/mingw64/include/harfbuzz -I/mingw64/include/glib-2.0 -I/mingw64/lib/glib-2.0/include -I/mingw64/include/libpng16 -L/mingw64/lib -LC:/building/msys64/mingw64/lib/../lib -L/mingw64/lib -lcairo -lz -lgobject-2.0 -lffi -lpixman-1 -lfontconfig -lexpat -lfreetype -liconv -lexpat -lfreetype -lz -lbz2 -lharfbuzz -lglib-2.0 -lintl -pthread -lws2_32 -lole32 -lwinmm -lshlwapi -lintl -lpng16 -lz

I'm not sure if I am doing something wrong or not, but I've been fiddling around with settings and Googling solutions for a while to no avail.

pkg-config-rs doesn't see available libraries in msys2

When I check if library presents in the system I get correct result.

$ pkg-config --libs --cflags cairo ; echo $?
-mms-bitfields -I/mingw64/include/cairo -I/mingw64/include/glib-2.0 -I/mingw64/lib/glib-2.0/include -I/mingw64/include/pixman-1 -I/mingw64/include -IC:/msys64/mingw64/include -IC:/msys64/mingw64/include/freetype2 -IC:/msys64/mingw64/include -IC:/msys64/mingw64/include/libpng16 -IC:/msys64/mingw64/include/harfbuzz -I/mingw64/include -I/mingw64/include/freetype2 -I/mingw64/include -I/mingw64/include/harfbuzz -I/mingw64/include/libpng16 -L/mingw64/lib -LC:/msys64/mingw64/lib/../lib -L/mingw64/lib -LC:/msys64/mingw64/lib -L/mingw64/lib -lcairo -lz -lgobject-2.0 -lffi -lglib-2.0 -lintl -pthread -lws2_32 -lole32 -lwinmm -lshlwapi -lintl -lpixman-1 -lfontconfig -lexpat -lfreetype -lexpat -lfreetype -lz -lbz2 -lharfbuzz -lpng16 -lz
0

But if I try to use it from rust with test code:

extern crate "pkg-config" as pkg_config;

fn main() {
    println!("{:?}", pkg_config::find_library("cairo"));
}

I get only.

Err("`\"pkg-config\" \"--libs\" \"--cflags\" \"cairo\"` did not exit successfully: exit code: 1\n--- stderr\nPackage cairo was not found in the pkg-config search path.\nPerhaps you should add the directory containing `cairo.pc\'\nto the PKG_CONFIG_PATH environment variable\nNo package \'cairo\' found\n")

PKG_CONFIG_PATH is "/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig"
rustc 1.0.0-dev (e98e39133 2015-03-20) (built 2015-03-20)

Yield nice errors in pkg-config isn't available

If you try to use this in a system where pkg-config is not installed (e.g. a fresh Ubuntu install) you get a rather cryptic panic

error: failed to run custom build command for `musync v0.1.0 (file:///home/bemeurer/src/musync)`
process didn't exit successfully: `/home/bemeurer/src/musync/target/release/build/musync-9f053b254a4fda51/build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'Failed to detect libmad: Command { command: "\"pkg-config\" \"--libs\" \"--cflags\" \"mad\"", cause: Error { repr: Os { code: 2, message: "No such file or directory" } } }', /checkout/src/libcore/result.rs:906:4

Shouldn't this give a more readable message simply saying pkg-config isn't installed?

Does not seem to consider PKG_CONFIG_PATH on Windows

See following output (it's the same with 0.3.9 and latest git of the pkg-config crate). This is with the MinGW target of Rust.

slomo@DESKTOP-63UL5V9 MSYS ~/gstreamer-rs
$ cargo build --all
    Updating git repository `https://github.com/alexcrichton/pkg-config-rs`
   Compiling pkg-config v0.3.9 (https://github.com/alexcrichton/pkg-config-rs#175dd559)
   Compiling glib-sys v0.4.0 (https://github.com/gtk-rs/sys#b08fc0e1)
error: failed to run custom build command for `glib-sys v0.4.0 (https://github.com/gtk-rs/sys#b08fc0e1)`
process didn't exit successfully: `C:\msys64\home\slomo\gstreamer-rs\target\debug\build\glib-sys-7dbb58e7b49d4edd\build-script-build` (exit code: 1)
--- stderr
`"pkg-config" "--libs" "--cflags" "glib-2.0 >= 2.32"` did not exit successfully: exit code: 1
--- stderr
Package glib-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `glib-2.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'glib-2.0' found


warning: build failed, waiting for other jobs to finish...
error: build failed

slomo@DESKTOP-63UL5V9 MSYS ~/gstreamer-rs
$ pkg-config --libs --cflags "glib-2.0 >= 2.32"
-mms-bitfields -I/c/gstreamer/1.0/x86_64/include/glib-2.0 -I/c/gstreamer/1.0/x86_64/lib/glib-2.0/include -L/c/gstreamer/1.0/x86_64/lib -lglib-2.0 -lintl -lws2_32 -lole32 -lwinmm -lshlwapi -lintl

slomo@DESKTOP-63UL5V9 MSYS ~/gstreamer-rs
$ echo $PKG_CONFIG_PATH
/c/gstreamer/1.0/x86_64/lib/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig:/lib/pkgconfig

Deprecated items being used

The compiler and RLS complaint about two deprecated items being used:

use of deprecated item 'std::ascii::AsciiExt': use inherent methods instead

note: #[warn(deprecated)] on by default

use of deprecated item 'core::str::<impl str>::trim_right': superseded by `trim_end`

It'll be better to removed such dependency on deprecated functionalities.

Does not always correctly parse OS X frameworks to link to

There are multiple ways that a framework to link to can be passed onto the linker:

-framework Framework
-Wl,-framework,Framework
-Wl,-framework -Wl,Framework

All 3 of these will effectively pass -framework Framework to the linker. The first one is currently supported by pkg-config-rs but the other 2 are not.

Also, theoritically this should also work:

-Wl,-framework,FrameworkA,-framework,FrameworkB

Improving cross-compilation experience

Currently pkg-config-rs tries to prevent incorrect use of pkg-config for cross-compilation:

Cross compilation detected. Use PKG_CONFIG_ALLOW_CROSS=1 to override

However, judging by questions on the Rust forum, users don't understand the problem. They only set the variable as instructed, and are disappointed that it still doesn't work.

I suggest changing this message to point users to a more complete explanation, e.g:

pkg-config must be configured for cross-compilation. See https://github.com/rust-lang/pkg-config-rs#how-to-cross-compile

which would then instruct users to set sysroot, etc. first before enabling PKG_CONFIG_ALLOW_CROSS=1.

Dependency being constantly rebuilt due to 'env_metadata' being set to 'true'

Hello, I'm having an issue with openssl-sys due to the changes made by #105 in pkg-config-rs
@sfackler led me here after I posted an issue on rust-openssl, so I'll repost it here :

On NixOS, to build openssl-sys you must be in a temporary environment where pkg-config and openssl are presents and their environment variables too (such as PKG_CONFIG_PATH), using nix-shell -p pkg-config openssl --run 'cargo build'

Previously, running this command once to build the crate was enough, I could then leave the environment and use cargo commands normally. But now (probably since a recent update ?) every time I leave the shell, and use cargo run/build, the crate gets recompiled (and fails because pkg-config is missing which is normal). Apparently, the fact the PKG_CONFIG_PATH environment variable changed triggers that rebuild.

As my IDE runs clippy on the fly (and so, without the appropriate environment to build openssl-sys), this feature becomes unusable as soon as openssl-sys gets in my project dependencies :/ I also can't use the run button from my IDE anymore.

Is there any workaround ?

Thanks by advance

Don't use deny(warnings) in code

https://github.com/alexcrichton/pkg-config-rs/blob/175dd5596fb8bf1ebf66c4df0c8d013e568c6d58/src/lib.rs#L65

This basically breaks for everyone when lints are changed because people do run tests ;)

I think more appropriate to pass -D warnings or something like that to CI.

pass cflags to gcc

In my Rust program, I want to use a C library (ffmpeg) with an API that's not Rust-friendly in a couple ways:

The API is partially defined in terms of macros such as this one, and I'd rather not have to duplicate their definitions (and hope they never change):
```
#define AVERROR_EOF                FFERRTAG( 'E','O','F',' ')
```

The caller is expected to directly access struct fields rather than use accessor functions, and the struct layout changes from version to version (hopefully paired with the appropriate .so major version increments, or even C callers are screwed when the library gets upgraded) and/or based on ifdefs, so duplicating the struct layouts in Rust is brittle. Here's an example (minus comments and such):

typedef struct AVPacket {
    AVBufferRef *buf;
    int64_t pts;
    int64_t dts;
    uint8_t *data;
    int   size;
    int   stream_index;
    int   flags;
    AVPacketSideData *side_data;
    int side_data_elems;
    int   duration;
#if FF_API_DESTRUCT_PACKET
    void  (*destruct)(struct AVPacket *);
    void  *priv;
#endif
    int64_t pos;
    int64_t convergence_duration;
} AVPacket;

(There's an existing Rust wrapper, but it took the duplication approach, and so there are problems if you compile against a different version than expected. I'd like to try another way.)

I want to make a tiny C library that simply provides a more Rust-friendly API surface: provides C functions to wrap the macros and access struct fields. So my Rust program will be using ffmpeg directly (for the parts that seem sensible/stable) and via my wrapper (for the rest).

I tried doing this via this simple build.rs:

extern crate gcc;
extern crate pkg_config;

fn main() {
    pkg_config::Config::new().atleast_version("54.1").probe("libavutil").unwrap();
    pkg_config::Config::new().atleast_version("56.0").probe("libavcodec").unwrap();
    pkg_config::Config::new().atleast_version("56.0").probe("libavformat").unwrap();
    gcc::Config::new()
        .file("wrapper.c")
        .compile("libwrapper.a");
}

but it looks like the cflags don't get passed to the gcc-built stuff; my #include <libavcodec/codec.h> doesn't work. Looking at pkg-config's source, I think I'd have to look at the pkg_config::Library, take the things that it carefully unpacked via parse_libs_cflags, and repack them into the cflags representation. That seems silly; I want a more direct way to pass them from pkg-config to gcc, as well as use them in my Rust program itself.

Add readme = "README.md" in cargo.toml to have the readme displayed on crates.io

Not a big deal but I think it would seem cleaner on crates.io (https://crates.io/crates/pkg-config).

At the moment the only thing displayed is the description.

Please consider stabilization toward 1.0

This crate has:

no direct dependencies
a quite stable API
a slow rate of changes
a lot of reverse dependencies

As such, it is a good target for downstream distributions to start tackling and designing strategies for effective crates integration into existing OS.

I would be very happy if you could start considering if the API is stable enough to quickly proceed toward a stable 1.0, and otherwise to write down what is missing to reach it, so that we can come up with a roadmap/patches for it.

Explicit Static Linking Failure

I'm trying to build the rust-ffmpeg-sys library with static linking.

What Happens

It fails to link statically and instead links some libraries dynamically because Config.statik doesn't fail if a static library couldn't be found.

https://github.com/meh/rust-ffmpeg-sys/blob/9056485f7fe4a42e3a68d08761b5a7817339da23/build.rs#L518-L521

What Should Happen

Terminal calls should throw if a static library is desired and couldn't be found. Maybe another function should be added with this behavior.

Ubuntu 18.04 cannot build (multiple imports and types errors)

Hi,

I am trying to build different libraries (mostly Rust-based Web servers) depending from this library in Ubuntu and I get consistently this error multiple times, with different libraries and different Rust versions (stable 1.29 and nightly 1.30.0) when running cargo build with a toml that specifies deps that requires pkg-config:

error: expected expression, found `]`                                                
  --> /home/lorenzo/.cargo/registry/src/github.com-1ecc6299db9ec823/pkg-config-0.1.7/src/lib.rs:70:60
   |                                                                                 
70 |             if options.statik && !is_system_lib(val, &dirs[]) {                 
   |                                                            ^ expected expression
                                                                                     
error[E0433]: failed to resolve. Could not find `old_io` in `std`                    
 --> /home/lorenzo/.cargo/registry/src/github.com-1ecc6299db9ec823/pkg-config-0.1.7/src/lib.rs:4:10
  |                                                                                  
4 | use std::old_io::fs::PathExtensions;                                             
  |          ^^^^^^ Could not find `old_io` in `std`                                 
                                                                                     
error[E0432]: unresolved import `std::old_io`                                        
 --> /home/lorenzo/.cargo/registry/src/github.com-1ecc6299db9ec823/pkg-config-0.1.7/src/lib.rs:3:10
  |                                                                                  
3 | use std::old_io::Command;                                                        
  |          ^^^^^^ Could not find `old_io` in `std`                                 
                                                                                     
error[E0433]: failed to resolve. Use of undeclared type or module `Path`             
  --> /home/lorenzo/.cargo/registry/src/github.com-1ecc6299db9ec823/pkg-config-0.1.7/src/lib.rs:65:23
   |                                                                                 
65 |             dirs.push(Path::new(val));                                          
   |                       ^^^^ Use of undeclared type or module `Path`              
                                                                                     
error[E0433]: failed to resolve. Use of undeclared type or module `Path`             
   --> /home/lorenzo/.cargo/registry/src/github.com-1ecc6299db9ec823/pkg-config-0.1.7/src/lib.rs:103:16
    |                                                                                
103 |     let root = Path::new("/usr");                                              
    |                ^^^^ Use of undeclared type or module `Path`                    
                                                                                     
error[E0425]: cannot find function `getenv` in module `os`                           
 --> /home/lorenzo/.cargo/registry/src/github.com-1ecc6299db9ec823/pkg-config-0.1.7/src/lib.rs:9:9
  |                                                                                  
9 |     os::getenv("HOST") == os::getenv("TARGET") ||                                
  |         ^^^^^^ not found in `os`                                                 
                                                                                     
error[E0425]: cannot find function `getenv` in module `os`                           
 --> /home/lorenzo/.cargo/registry/src/github.com-1ecc6299db9ec823/pkg-config-0.1.7/src/lib.rs:9:31
  |                                                                                  
9 |     os::getenv("HOST") == os::getenv("TARGET") ||                                
  |                               ^^^^^^ not found in `os`                           
                                                                                     
error[E0425]: cannot find function `getenv` in module `os`                           
  --> /home/lorenzo/.cargo/registry/src/github.com-1ecc6299db9ec823/pkg-config-0.1.7/src/lib.rs:10:13
   |                                                                                 
10 |         os::getenv("PKG_CONFIG_ALLOW_CROSS") == Some("1".to_string())           
   |             ^^^^^^ not found in `os`                                            
                                                                                     
error[E0425]: cannot find function `getenv` in module `os`                           
  --> /home/lorenzo/.cargo/registry/src/github.com-1ecc6299db9ec823/pkg-config-0.1.7/src/lib.rs:23:12
   |                                                                                 
23 |     if os::getenv(format!("{}_NO_PKG_CONFIG", envify(name)).as_slice()).is_some() {
   |            ^^^^^^ not found in `os`                                             
                                                                                     
error[E0425]: cannot find function `getenv` in module `os`                           
  --> /home/lorenzo/.cargo/registry/src/github.com-1ecc6299db9ec823/pkg-config-0.1.7/src/lib.rs:82:25
   |                                                                                 
82 |     let statik = if os::getenv(format!("{}_STATIC", name).as_slice()).is_some() {
   |                         ^^^^^^ not found in `os`                                
                                                                                     
error[E0425]: cannot find function `getenv` in module `os`                           
  --> /home/lorenzo/.cargo/registry/src/github.com-1ecc6299db9ec823/pkg-config-0.1.7/src/lib.rs:84:19
   |                                                                                 
84 |     } else if os::getenv(format!("{}_DYNAMIC", name).as_slice()).is_some() {    
   |                   ^^^^^^ not found in `os`                                      
                                                                                     
error[E0425]: cannot find function `getenv` in module `os`                           
  --> /home/lorenzo/.cargo/registry/src/github.com-1ecc6299db9ec823/pkg-config-0.1.7/src/lib.rs:86:19
   |                                                                                 
86 |     } else if os::getenv("PKG_CONFIG_ALL_STATIC").is_some() {                   
   |                   ^^^^^^ not found in `os`                                      
                                                                                     
error[E0425]: cannot find function `getenv` in module `os`                           
  --> /home/lorenzo/.cargo/registry/src/github.com-1ecc6299db9ec823/pkg-config-0.1.7/src/lib.rs:88:19
   |                                                                                 
88 |     } else if os::getenv("PKG_CONFIG_ALL_DYNAMIC").is_some() {                  
   |                   ^^^^^^ not found in `os`                                      
                                                                                     
error[E0412]: cannot find type `Path` in this scope                                  
   --> /home/lorenzo/.cargo/registry/src/github.com-1ecc6299db9ec823/pkg-config-0.1.7/src/lib.rs:101:38
    |                                                                                
101 | fn is_system_lib(name: &str, dirs: &[Path]) -> bool {                          
    |                                      ^^^^ not found in this scope              
help: possible candidate is found in another module, you can import it into scope    
    |                                                                                
3   | use std::path::Path;                                                           
    |                                                                                
                                                                                     
error[E0599]: no method named `as_slice` found for type `std::string::String` in the current scope
  --> /home/lorenzo/.cargo/registry/src/github.com-1ecc6299db9ec823/pkg-config-0.1.7/src/lib.rs:23:61
   |                                                                                 
23 |     if os::getenv(format!("{}_NO_PKG_CONFIG", envify(name)).as_slice()).is_some() {
   |                                                             ^^^^^^^^            
                                                                                     
error[E0599]: no method named `as_slice` found for type `std::string::String` in the current scope
  --> /home/lorenzo/.cargo/registry/src/github.com-1ecc6299db9ec823/pkg-config-0.1.7/src/lib.rs:82:59
   |                                                                                 
82 |     let statik = if os::getenv(format!("{}_STATIC", name).as_slice()).is_some() {
   |                                                           ^^^^^^^^              
                                                                                     
error[E0599]: no method named `as_slice` found for type `std::string::String` in the current scope
  --> /home/lorenzo/.cargo/registry/src/github.com-1ecc6299db9ec823/pkg-config-0.1.7/src/lib.rs:84:54
   |                                                                                 
84 |     } else if os::getenv(format!("{}_DYNAMIC", name).as_slice()).is_some() {    
   |                                                      ^^^^^^^^                   
                                                                                     
   Compiling linked-hash-map v0.4.2                                                  
error[E0369]: binary operation `==` cannot be applied to type `std::char::ToUppercase`
  --> /home/lorenzo/.cargo/registry/src/github.com-1ecc6299db9ec823/pkg-config-0.1.7/src/lib.rs:97:55
   |                                                                                 
97 |     name.chars().map(|c| c.to_uppercase()).map(|c| if c == '-' {'_'} else {c})  
   |                                                       ^^^^^^^^                  
   |                                                                                 
   = note: an implementation of `std::cmp::PartialEq` might be missing for `std::char::ToUppercase`
                                                                                     
error[E0308]: if and else have incompatible types                                    
  --> /home/lorenzo/.cargo/registry/src/github.com-1ecc6299db9ec823/pkg-config-0.1.7/src/lib.rs:97:52
   |                                                                                 
97 |     name.chars().map(|c| c.to_uppercase()).map(|c| if c == '-' {'_'} else {c})  
   |                                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^ expected char, found struct `std::char::ToUppercase`
   |                                                                                 
   = note: expected type `char`                                                      
              found type `std::char::ToUppercase`                                    
                                                                                     
error: aborting due to 19 previous errors                                            
                                                                                     
Some errors occurred: E0308, E0369, E0412, E0425, E0432, E0433, E0599.               
For more information about an error, try `rustc --explain E0308`.                    
error: Could not compile `pkg-config`.

I did a brief investigation on the dependency tree and found out that:

pkg-config
├── pkg-config v0.3.14
    │       └── pkg-config v0.1.7

the newest version depends from the old one (0.1.7), that breaks the build.
This is the Dockerfile I am using to build the containers:

RUN apt-get install -y wget build-essential software-properties-common curl pkg-config \
                       libssh-dev cmake

ENV RUSTUP_HOME=/usr/local/rustup \
    CARGO_HOME=/usr/local/cargo \
    PATH=/usr/local/cargo/bin:$PATH

RUN set -eux; \
    \
    url="https://static.rust-lang.org/rustup/dist/x86_64-unknown-linux-gnu/rustup-init"; \
    wget "$url"; \
    chmod +x rustup-init; \
    ./rustup-init -y --no-modify-path --default-toolchain stable; \   # or nightly is the same
    rm rustup-init; \
    chmod -R a+w $RUSTUP_HOME $CARGO_HOME; \
    rustup --version; \
    cargo --version; \
    rustc --version;

CMD ["cargo", "build"]

NOTE: i get the same error on my local machine outside the container.

Use of StaticMutex in tests is going to break

rust-lang/rust#34705

	fn is_static_available(name: &str, dirs: &[PathBuf]) -> bool {
	let libname = format!("lib{}.a", name);
	let system_roots = if cfg!(target_os = "macos") {
	vec![Path::new("/Library"), Path::new("/System")]
	} else {
	vec![Path::new("/usr")]
	};

	dirs.iter().any(\|dir\| {
	!system_roots.iter().any(\|sys\| dir.starts_with(sys)) && dir.join(&libname).exists()
	})
	}