-
-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pam-sys
crate won't build; ENOENT on #include <security/pam_appl.h>
#326
Comments
See the existing overrides that include darwin components. Looks like you need:
|
Doesn't that apply only if the Mine's Linux
|
Sorry, it was late and I was just scanning through and saw
The usual way this gets picked up is pkgconfig and some hooks that set the include flags for all the dependencies. Sometimes you need to switch outputs to get the right files. Check outputs to see if there's a dev output.
Nope, standard. Skipping ahead, the outPath include/security directory does contain pam_appl.h Can you get me the output for |
Was Clang in that flake before? |
I uh...I don't remember why I put that there. If I take it out, I get the same error. But if I take out `LIBCLANG_PATH` too, I get
Anyway: nix derivation show
env | sortAfter repeating all
|
Oh, my bad. If you look through the existing overrides, most of the sys packages use
|
Alas, I'm still doing something wrong
|
When sys crates fail, often we can look at the build.rs script trying to do something that assumes it has access to everything. Build.rs scripts don't always interpret the provided environment correctly. https://github.com/1wilkens/pam-sys/blob/master/build.rs It's using bindgen. Can you print your environment again now that libpam is included in buildInputs? There should be a way to pass an option for the location directly to the build script and enable it to find your libraries. |
env | grep -i pam
|
I'd like to try and build this later and see what's not grepped. If you can strip down the example, that would help. I am suspicious of why clang is involved at all. Pam has been around since a long time before clang. |
I can try:
pam-sys 1.0.0-alpha4 "registry+https://github.com/rust-lang/crates.io-index".pam-sys."1.0.0-alpha4" = overridableMkRustCrate (profileName: rec {
name = "pam-sys";
version = "1.0.0-alpha4";
registry = "registry+https://github.com/rust-lang/crates.io-index";
src = fetchCratesIo { inherit name version; sha256 = "5e9dfd42858f6a6bb1081079fd9dc259ca3e2aaece6cb689fd36b1058046c969"; };
dependencies = {
libc = rustPackages."registry+https://github.com/rust-lang/crates.io-index".libc."0.2.126" { inherit profileName; };
};
buildDependencies = {
bindgen = buildRustPackages."registry+https://github.com/rust-lang/crates.io-index".bindgen."0.59.2" { profileName = "__noProfile"; };
};
});
Another possibility: |
I found out why Clang is involved:
The link further in that paragraph about I recently updated my flake and caused myself a cascade of more headaches: now
But I'm guessing that's fixable with an override. I'll write back when I have more information. |
I just shotgunned includes (turns out their order matters too) until `pam-sys` started buildingdiff --git a/flake.nix b/flake.nix
index b2a4784..1406d81 100644
--- a/flake.nix
+++ b/flake.nix
@@ -5,7 +5,8 @@
nixpkgs.follows = "cargo2nix/nixpkgs";
};
outputs = inputs:
with inputs;
+ mkInclude = pkg: dir: "-I${pkg}/${dir}"; in
flake-utils.lib.eachDefaultSystem (
system: let
pkgs = import nixpkgs {
@@ -26,7 +27,13 @@
(pkgs.rustBuilder.rustLib.makeOverride {
name = "pam-sys";
overrideAttrs = old: {
- BINDGEN_EXTRA_CLANG_ARGS = "-I${pkgs.linux-pam}/include -I${pkgs.linuxHeaders}/include -I${pkgs.linuxHeaders}/include/linux -I${pkgs.glibc.dev}/include -I${pkgs.clang}/resource-root/include";
+ BINDGEN_EXTRA_CLANG_ARGS = pkgs.lib.strings.concatStringsSep " "
+ [
+ (mkInclude pkgs.clang "resource-root/include")
+ (mkInclude pkgs.linuxHeaders "include")
+ (mkInclude pkgs.glibc.dev "include")
+ (mkInclude pkgs.linux-pam "include")
+ ];
LIBCLANG_PATH = pkgs.lib.makeLibraryPath [pkgs.llvmPackages.libclang.lib];
};
})
the Nix builder can't find proc-macro2
but that's a story for another issue, if I get too stuck to figure it out myself again. |
I reopened because I didn't have time to check why this closed. TLDR lol |
My bad. TL;DR version: I needed to supply |
As for the
and Nix is trying to build the |
I'm working on a program (here's its flake) that transitively depends on
pam-sys
, which generates FFI bindings to PAM headers.I can't get cargo to see those headers, though:
nix log /nix/store/jcg61291wl1fqwg66fc4gkazq9h9x39a-crate-pam-sys-1.0.0-alpha4.drv
With a shell in the build environment, I can see cargo (gcc?) probing $PWD for the header, but nowhere else.
Which is weird, because I can see the include flag for
linux-pam
in the environment:Forgive me if I've missed something basic. My C is rusty.
The text was updated successfully, but these errors were encountered: