Skip to content
This repository has been archived by the owner on Jun 2, 2020. It is now read-only.

Unable to initialize application with extensions with nightly cargo. #164

Closed
peterhuene opened this issue Feb 20, 2019 · 4 comments
Closed
Labels
bug Something isn't working
Milestone

Comments

@peterhuene
Copy link
Owner

Steps to reproduce

  1. rustup default nightly.
  2. cargo install -f azure-functions-sdk.
  3. cargo func new-app repro.
  4. cargo func new blob -n repro --path repro.
  5. cargo func run.

Expected behavior

The application starts successfully.

Actual behavior

Initializing the application fails because dotnet (used to restore the Azure Functions storage extension required for blob triggers) can't find libproc:

System.DllNotFoundException: Unable to load shared library 'libproc' or one of its dependencies. In order to help diagnose loading problems, consider setting the DYLD_PRINT_LIBRARIES environment variable: dlopen(liblibproc, 1): image not found
   at Interop.libproc.proc_pidpath(Int32 pid, Byte* buffer, UInt32 bufferSize)
   at Interop.libproc.proc_pidpath(Int32 pid)
   at System.Diagnostics.Process.ResolvePath(String filename)
   at System.Diagnostics.Process.StartCore(ProcessStartInfo startInfo)
   at System.Diagnostics.Process.Start()
   at Microsoft.DotNet.Cli.Utils.ProcessStartInfoExtensions.Execute(ProcessStartInfo startInfo)
   at Microsoft.DotNet.Tools.RestoringCommand.Execute()
   at Microsoft.DotNet.Tools.Publish.PublishCommand.Run(String[] args)
   at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, ITelemetry telemetryClient)
   at Microsoft.DotNet.Cli.Program.Main(String[] args)

Environment information (OS, versions, etc.)

Azure Functions for Rust: 0.4.1
OS: macOS 10.14

@peterhuene peterhuene added the bug Something isn't working label Feb 20, 2019
@peterhuene peterhuene added this to the 0.5.0 milestone Feb 20, 2019
@peterhuene
Copy link
Owner Author

There's no problem with the same dotnet spawned from a stable cargo.

Possibly an environment issue that's causing nightly to mess with the lib path?

@peterhuene
Copy link
Owner Author

peterhuene commented Feb 20, 2019

Sure looks like cargo is messing with DYLD environment variables:

$ diff stable nightly
3c3
< CARGO: /Users/peterhuene/.rustup/toolchains/stable-x86_64-apple-darwin/bin/cargo
---
> CARGO: /Users/peterhuene/.rustup/toolchains/nightly-x86_64-apple-darwin/bin/cargo
19c19,20
< DYLD_LIBRARY_PATH: /Users/peterhuene/src/azure-functions-rs/target/debug/build/grpcio-sys-e033b2c79a1901bc/out:/Users/peterhuene/src/azure-functions-rs/target/debug/build/grpcio-sys-e033b2c79a1901bc/out/build:/Users/peterhuene/src/azure-functions-rs/target/debug/build/grpcio-sys-e033b2c79a1901bc/out/build/third_party/boringssl/crypto:/Users/peterhuene/src/azure-functions-rs/target/debug/build/grpcio-sys-e033b2c79a1901bc/out/build/third_party/boringssl/ssl:/Users/peterhuene/src/azure-functions-rs/target/debug/build/grpcio-sys-e033b2c79a1901bc/out/build/third_party/cares/cares/lib:/Users/peterhuene/src/azure-functions-rs/target/debug/build/grpcio-sys-e033b2c79a1901bc/out/build/third_party/zlib:/Users/peterhuene/src/azure-functions-rs/target/debug/deps:/Users/peterhuene/src/azure-functions-rs/target/debug:/Users/peterhuene/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib:/Users/peterhuene/.rustup/toolchains/stable-x86_64-apple-darwin/lib:/Users/peterhuene/.rustup/toolchains/stable-x86_64-apple-darwin/lib
---
> DYLD_FALLBACK_LIBRARY_PATH: /Users/peterhuene/src/azure-functions-rs/target/debug/build/grpcio-sys-de2528deedfccd8b/out:/Users/peterhuene/src/azure-functions-rs/target/debug/build/grpcio-sys-de2528deedfccd8b/out/build:/Users/peterhuene/src/azure-functions-rs/target/debug/build/grpcio-sys-de2528deedfccd8b/out/build/third_party/boringssl/crypto:/Users/peterhuene/src/azure-functions-rs/target/debug/build/grpcio-sys-de2528deedfccd8b/out/build/third_party/boringssl/ssl:/Users/peterhuene/src/azure-functions-rs/target/debug/build/grpcio-sys-de2528deedfccd8b/out/build/third_party/cares/cares/lib:/Users/peterhuene/src/azure-functions-rs/target/debug/build/grpcio-sys-de2528deedfccd8b/out/build/third_party/zlib:/Users/peterhuene/src/azure-functions-rs/target/debug/deps:/Users/peterhuene/src/azure-functions-rs/target/debug:/Users/peterhuene/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib
> DYLD_LIBRARY_PATH: /Users/peterhuene/.rustup/toolchains/nightly-x86_64-apple-darwin/lib:/Users/peterhuene/.rustup/toolchains/nightly-x86_64-apple-darwin/lib
34c35
< RUSTUP_TOOLCHAIN: stable-x86_64-apple-darwin
---
> RUSTUP_TOOLCHAIN: nightly-x86_64-apple-darwin

@peterhuene
Copy link
Owner Author

Looks like this will fix it: rust-lang/cargo#6625.

@peterhuene
Copy link
Owner Author

Confirmed fixed with a more recently nightly.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant