Incorrect library path for MacOS tools?

[tschundler]

Bug description

espup on MacOS is looking for libraries in an incorrect place for my system.

• Would you like to work on a fix? n

To Reproduce

Given install:

cargo install espup
espup install
. ~/export-esp.sh

I get an error running cargo:

$ cargo version
dyld[76858]: Library not loaded: '/usr/local/opt/openssl@3/lib/libcrypto.3.dylib'
  Referenced from: '/Users/ted/.rustup/toolchains/esp/bin/cargo'
  Reason: tried: '/usr/local/opt/openssl@3/lib/libcrypto.3.dylib' (no such file), '/Users/ted/.rustup/toolchains/esp/lib/libcrypto.3.dylib' (no such file), '/Users/ted/lib/libcrypto.3.dylib' (no such file), '/usr/local/lib/libcrypto.3.dylib' (no such file), '/usr/lib/libcrypto.3.dylib' (no such file)
Abort trap: 6

my libssl.3.dylib & libcrypto.3.dylib live in /opt/local/lib/

Expected behavior

cargo works

Environment

• OS: MacOS 12.6
• espup version: 0.2.5

Additional context

Maybe they could be statically linked? Or shipped with the binary and put in ~/.rustup/toolchains/esp/lib/ ?

[tschundler]

(I've copied the files over myself and have working cargo, but this could possibly block others)

[SergioGasquez]

Hi @tschundler!

Thanks for reporting this issue, could you try the installation with the PR branch to verify that it solves the issue?

cargo install espup --git https://github.com/esp-rs/espup --branch fix/mac-openssl
espup install
. ~/export-esp.sh

[tschundler]

oops. I probably should have been more specific about running cargo.

I create a new esp32s3 project, eg

cargo generate --git https://github.com/esp-rs/esp-template -n esps3-test
cd esps3-test

then run

cargo version

and that's what isn't statically linked, when it uses cargo in ~/.espressif/dist/rust/rust-nightly-x86_64-apple-darwin/cargo/bin/cargo

$ otool -L ~/.espressif/dist/rust/rust-nightly-x86_64-apple-darwin/cargo/bin/cargo
/Users/ted/.espressif/dist/rust/rust-nightly-x86_64-apple-darwin/cargo/bin/cargo:
        /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
        /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 59306.101.1)
        /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1675.129.0)
        /usr/local/opt/openssl@3/lib/libssl.3.dylib (compatibility version 3.0.0, current version 3.0.0)
        /usr/local/opt/openssl@3/lib/libcrypto.3.dylib (compatibility version 3.0.0, current version 3.0.0)
        /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
        /usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 9.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)

(on an M1 mac, it's fine. otool -L ~/.espressif/dist/rust/rust-nightly-aarch64-apple-darwin/cargo/bin/cargo doesn't list libssl, libcrypto or libz, so they must be statically linked)

...digging more, /usr/local/opt/lib seems to be a homebrew thing, so I tried brew install openssl and that put it in the expected location. Still, it should probably be static linked.

I'm not sure who owns building that special nightly rust toolchain - maybe this bug should be in a different place?

[SergioGasquez]

oops. I probably should have been more specific about running cargo.

I create a new esp32s3 project, eg

cargo generate --git https://github.com/esp-rs/esp-template -n esps3-test
cd esps3-test

then run

cargo version

and that's what isn't statically linked, when it uses cargo in ~/.espressif/dist/rust/rust-nightly-x86_64-apple-darwin/cargo/bin/cargo

$ otool -L ~/.espressif/dist/rust/rust-nightly-x86_64-apple-darwin/cargo/bin/cargo
/Users/ted/.espressif/dist/rust/rust-nightly-x86_64-apple-darwin/cargo/bin/cargo:
        /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
        /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 59306.101.1)
        /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1675.129.0)
        /usr/local/opt/openssl@3/lib/libssl.3.dylib (compatibility version 3.0.0, current version 3.0.0)
        /usr/local/opt/openssl@3/lib/libcrypto.3.dylib (compatibility version 3.0.0, current version 3.0.0)
        /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
        /usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 9.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)

(on an M1 mac, it's fine. otool -L ~/.espressif/dist/rust/rust-nightly-aarch64-apple-darwin/cargo/bin/cargo doesn't list libssl, libcrypto or libz, so they must be statically linked)

...digging more, /usr/local/opt/lib seems to be a homebrew thing, so I tried brew install openssl and that put it in the expected location. Still, it should probably be static linked.

I'm not sure who owns building that special nightly rust toolchain - maybe this bug should be in a different place?

Sorry, is this the output of testing the fix/mac-openssl branch? In this branch, openssl should be statically linked

[paazmaya]

After updating to fix/mac-openssl branch, while having the esp toolchain active, the command cargo version has the following output on mac:

dyld: Library not loaded: /usr/local/opt/openssl@3/lib/libssl.3.dylib
  Referenced from: /Users/paazmaya/.rustup/toolchains/esp/bin/cargo
  Reason: image not found
Abort trap: 6

[tschundler]

The problem isn't with espup itself, but with the rust-nightly that espup installs. That cargo, that it puts in ~/.rustup/toolchains/esp/bin/cargo is what doesn't have openssl static linked.

The location it expects is where http://brew.sh puts it, not a standard MacOS location. I have no problem otherwise with cargo from https://rustup.rs/, only what espup installs.

Is there somewhere better for the bug to be?

[SergioGasquez]

Is there somewhere better for the bug to be?

Probably, could you open up an issue in https://github.com/esp-rs/rust-build with your conclusions? I will still merge #153 as I think its an improvement

[tschundler]

Ack, found existing bug esp-rs/rust-build#157

For @paazmaya , using homebrew to install openssl is a work-around that is working for me. (All the LLVM stuff for xtensa is resole, right? So we shouldn't need a special toolchain much longer?)

[SergioGasquez]

Ack, found existing bug esp-rs/rust-build#157

Sorry I completely forgot about that issue, where I also participated

All the LLVM stuff for xtensa is resole, right? So we shouldn't need a special toolchain much longer?

Yes, the first 10 patches have now been accepted, hopefully, we will have Xtensa support in LLVM and Rust in the future!