Build roc with llvm musl

[Anton-4]

We've talked about this a lot but it's nice to have an issue for tracking.

[Anton-4]

Current state (copied from zulip):

================================

these are the instructions for reproduction and the error:

git clone https://github.com/Anton-4/zig-bootstrap.git
cd zig-bootstrap
./build x86_64-linux-musl baseline

cd into roc-repo

! use correct path for your case

export LLVM_SYS_160_PREFIX=/home/username/gitrepos/zig-bootstrap/out/x86_64-linux-musl-baseline/
cargo build --release --bin roc

error:

❯ cargo build --release --bin roc
Compiling roc_cli v0.0.1 (/home/username/gitrepos/roc/crates/cli)
error: linking with cc failed: exit status: 1
|
= note: LC_ALL="C" PATH="/home/username/.rustup/toolchains/1.71.1-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/home/username/.cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin:/home/username/Downloads/zig-linux-x86_64-0.11.0" VSLANG="1033" "cc" "-m64" "/tmp/rustc6K8wb3/symbols.o" ... "-Wl,-O1" "-nodefaultlibs"
= note: /usr/bin/ld: /home/username/gitrepos/roc/target/release/deps/libllvm_sys-9da5a9aa4a1ab08e.rlib(X86AsmParser.cpp.o): in function (anonymous namespace)::X86AsmParser::VerifyAndAdjustOperands(llvm::SmallVectorImpl<std::__1::unique_ptr<llvm::MCParsedAsmOperand, std::__1::default_delete<llvm::MCParsedAsmOperand> > >&, llvm::SmallVectorImpl<std::__1::unique_ptr<llvm::MCParsedAsmOperand, std::__1::default_delete<llvm::MCParsedAsmOperand> > >&)': X86AsmParser.cpp:(.text._ZN12_GLOBAL__N_112X86AsmParser23VerifyAndAdjustOperandsERN4llvm15SmallVectorImplINSt3__110unique_ptrINS1_18MCParsedAsmOperandENS3_14default_deleteIS5_EEEEEESA_+0x26e): undefined reference to std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > std::__1::operator+<char, std::__1::char_traits, std::__1::allocator >(char const*, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&)'
/usr/bin/ld: X86AsmParser.cpp:(.text.ZN12_GLOBAL__N_112X86AsmParser23VerifyAndAdjustOperandsERN4llvm15SmallVectorImplINSt3__110unique_ptrINS1_18MCParsedAsmOperandENS3_14default_deleteIS5_EEEEEESA+0x27d): undefined reference to std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::append(char const*)' /usr/bin/ld: /home/username/gitrepos/roc/target/release/deps/libllvm_sys-9da5a9aa4a1ab08e.rlib(X86TargetMachine.cpp.o): in function LLVMInitializeX86Target':
X86TargetMachine.cpp:(.text.LLVMInitializeX86Target+0x101): undefined reference to `std::__1::__call_once(unsigned long volatile&, void*, void ()(void))'

[...]

      /usr/bin/ld: /home/username/gitrepos/roc/target/release/deps/libllvm_sys-9da5a9aa4a1ab08e.rlib(AArch64PBQPRegAlloc.cpp.o):(.data.rel.ro._ZTVNSt3__120__shared_ptr_emplaceIN4llvm4PBQP9ValuePoolINS2_8MDMatrixINS2_8RegAlloc14MatrixMetadataEEEE9PoolEntryENS_9allocatorIS9_EEEE[_ZTVNSt3__120__shared_ptr_emplaceIN4llvm4PBQP9ValuePoolINS2_8MDMatrixINS2_8RegAlloc14MatrixMetadataEEEE9PoolEntryENS_9allocatorIS9_EEEE]+0x28): undefined reference to `std::__1::__shared_weak_count::__get_deleter(std::type_info const&) const'
      collect2: error: ld returned 1 exit status

= note: some extern functions couldn't be found; some native libraries may need to be installed or have their path specified
= note: use the -l flag to specify native libraries to link
= note: use the cargo:rustc-link-lib directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname)

error: could not compile roc_cli (bin "roc") due to previous error

The important part seems to be undefined reference to std::__1::basic_string...`
Brendan Hansknecht
5:05 PM

I wonder if we also need to build and link against llvm libc++? Cause this seems like it could be a libc++ versioning issue, which could be related to trying to build static which means it can't dynamically pull in the system libc++. That said, a bit surprised it fails on roc and not during llvm compilation. That suggests that whatever it needs is defined somewhere in the llvm build process and we just aren't pulling it in (maybe not that surprising cause llvm-sys probably expects a dynamic llvm which automagically pulls in it's own dependencies).

[Anton-4]

I think we determined this requires llvm 18 to work around a bug, do you remember who last did some work on llvm musl @lukewilliamboswell? Do we have a branch for it?

[lukewilliamboswell]

We should be good to use musl once we upgrade to llvm 18. Ryan and I were working on that, and I think the issue was a bug or something in 16 which prevented us from using it.

[lukewilliamboswell]

The llvm upgrade branch is mostly done, and least the bulk of the upgrade changes for llvm and zig etc. The latest was it needed some CI machine stuff to land, and there was a couple of smaller things. The plan was to merge the changes after the prebuilt host PR.