Doc request and question regarding where and how to align LLVM versions

[EdmundsEcho]

This seems like a great tool. I look forward to giving it go! And thus my post.

Despite the documentation already in place that touches on how to align LLVM versions, I identified the following "gaps" (leave it me to come from an unusual angle :)):

1. I have a .bc file generated using a project specific rustup override set 14.0.6 => compatible with llvm-ir Note: I confirmed the rustc version from within the root directory cargo rustc -- --version --verbose and rustup settings.toml/[overrides]

2. I have a separate project that follows the "getting-started" documentation for llvm-ir (or -analytics) using the feature gated features = ["llvm-14"]

   • attempt 1: use rustc 1.70 and its paired LLVM version 16 => it should be able to use the latest rustc to compile b/c I have already aligned the parser version with the .bc file I expect it to parse

   • attempt 2: use rustc 1.63.0 and its paired LLVM version 14.0.5 => compiler error (in the build script):

   ...
   cargo:rustc-link-search=native=/opt/homebrew/Cellar/llvm/16.0.0/lib
   ...
   thread 'main' panicked at 'system library flag "/opt/homebrew/lib/libz3.dylib" does not look like a link library', /Users/edmund/.cargo/registry/src/github.com-1ecc6299db9ec823/llvm-sys-140.1.1/build.rs:284:17

I looked at the rustc configuration options... and other places.

A question and a request for information:

1. Attempt 1 may have failed only because the .bc file was compiled using rustc 16 despite my use of the rustup override. But otherwise my logic is sound. Is it? It's not clear that the chosen feature-gate version means I must also use that LLVM to compile the parsing app.

2. May I ask how to set the rustc path to the one I set using the rustup override command? (i.e., ignore the instance likely installed when I installed rustup).
   Perhaps as an aside: It failing here makes me think the feature-gate needs to align with the compiler not just of the .bc file from another project, but with the "viewer/parser" itself (that would be worth documenting one way or another).

One last potential clue (where my understanding of how things work get fuzzy): I'm using M1 where, early-on, I needed to create rustflags for the C linkers (hosted in my .cargo/config.toml target-specific entries. I'm hesitant to point the blame here b/c I haven't had issues toggling between cargo versions, but maybe in this setting it might be a source of trouble? (given explicit/face-value interpretation of the error message).

Thank you!

[EdmundsEcho]

... peeling the onion some more.

The following comes from llvm-sys which suggests how to set the specific LLVM version. I just have not figured out how to implement it:

Depending on your use of the C API, your program may require that only a version of LLVM exactly matching your crate version be allowed. This can be set with the cargo feature flag strict-versioning or by setting the environment variable LLVM_SYS_<version>_STRICT_VERSIONING (where is the target crate version) to any value.

I can't fully understand how to follow-through on that guidance, but what I know is that it fails when I run the build with

set -x LLVM_SYS_140_PREFIX /opt/homebrew/Cellar/llvm@14/14.0.6/bin; cargo build

[cdisselkoen]

If you look at our Cargo.toml, we have feature flags like llvm-14-strict that enable the strict-versioning feature of llvm-sys. Does that help?

[EdmundsEcho]

Good idea... but unfortunately no. Here is the error I get when I moved the system version to ~/Desktop (to avoid it linking to default sys).

> set -x LLVM_SYS_140_PREFIX /opt/homebrew/Cellar/llvm@14/14.0.6/bin; cargo build

 Compiling llvm-sys v140.1.1
   Compiling llvm-ir v0.9.0
error: No suitable version of LLVM was found system-wide or pointed
              to by LLVM_SYS_140_PREFIX.

              Consider using `llvmenv` to compile an appropriate copy of LLVM, and
              refer to the llvm-sys documentation for more information.

              llvm-sys: https://crates.io/crates/llvm-sys
              llvmenv: https://crates.io/crates/llvmenv
   --> /Users/edmund/.cargo/registry/src/github.com-1ecc6299db9ec823/llvm-sys-140.1.1/src/lib.rs:487:1
    |
487 | / std::compile_error!(concat!(
488 | |     "No suitable version of LLVM was found system-wide or pointed
489 | |        to by LLVM_SYS_",
490 | |     env!("CARGO_PKG_VERSION_MAJOR"),
...   |
497 | |        llvmenv: https://crates.io/crates/llvmenv"
498 | | ));
    | |__^

error: could not compile `llvm-sys` due to previous error

[cdisselkoen]

A belated response to something you said in your original post:

It's not clear that the chosen feature-gate version means I must also use that LLVM to compile the parsing app.

Generally, LLVM can read bitcode generated with older LLVM but not newer. For instance, LLVM 14 can read bitcode generated with LLVM 14 or 12, but not 16. If your bitcode was generated with LLVM X, you need to use an llvm-ir feature of at least X.

To some of your other questions, I have very little knowledge about advanced rustc usage, unfortunately.

I did just notice something in your last message -- did you try setting LLVM_SYS_140_PREFIX to the 14.0.6 directory, not the bin subdirectory? I believe that's required by llvm-sys

[cdisselkoen]

Closing this as stale and presumed resolved. Feel free to reopen if this is incorrect.