lib/ vs lib64/

[milibopp]

Just tried compiling this crate on a 64-bit NixOS system.

And I ran into the issue that the compiled native libffi ended up in a lib64/ folder, not in lib/. So changing line 23 of build.rs from

let libdir = Path::new(&prefix).join("lib");

to

let libdir = Path::new(&prefix).join("lib64");

made it compile for me. I assume a more robust solution would be to just add both variants to the search path for rustc?

For reference, this is the Nix expression I used to setup the environment:

with import <nixpkgs> {};

stdenv.mkDerivation {
  name = "libffi-rs-sys";
  src = ./.;
  LIBCLANG_PATH = "${llvmPackages.clang.cc}/lib";
  buildInputs = [ automake file gnum4 libtool clang texinfo autoconf rustc cargo ];
}

[tov]

Thanks for the report. I suppose we could just put both in the search path, unless there's a way to ask the environment for where to look?

[milibopp]

Well, you could determine the architecture easily. But I wouldn't take the chance to assume, that it always corresponds. I bet you have compiled this with lib/ successfully on other 64-bit systems, otherwise this issue would have come up sooner.

One would have to figure out, how this is determined by autotools (I guess?). But then the build process probably becomes more tightly coupled to how libffi is built, which may be harder to maintain in the long run.

Should I create PR adding both to the search path?

[tov]

Unfortunately, 64-bit architecture doesn't necessarily mean it will be in lib64/, so I think we should just look in both, hoping there aren’t additional places to look. No need for a PR—I just pushed the change. Does it work for you?

[milibopp]

Yes, it works now. Thanks! Closing this.

[tov]

Okay, I am releasing this as 0.5.3. Thanks!