release/18.x: [cmake] Add minor version to library SONAME (#79376)

[llvmbot]

Backport 91a3846

Requested by: @tstellar

[llvmbot]

@jyknight What do you think about merging this PR to the release branch?

[RalfJung]

Making such a fundamental change to the .so file so late in the release was probably a bad idea... a bunch of downstream projects will have to adjust the way they link with LLVM and that's not always easy.

[tstellar]

@RalfJung The intention was that the change would be backwards compatible. Is there a specific problem you see? We can still fix this in the release/18.x branch if necessary.

[RalfJung]

Yeah, I linked to it: rust-lang/rust#121889.

I'm not a linker expert, but it seems that now symlinks are required to link against the LLVM .so file, but we can't ship symlinks in our artifacts because of Windows. The old approach we used of just shipping the .so file and pointing the linker at it doesn't seem to work any more with the new sonames. I don't claim to understand why, I am involved solely because the tool I work on (which links against rustc directly, and thus against LLVM) no longer builds after rustc updated to LLVM 18 rc4.

A solution is in the works though so we may be fine soon. But who knows which other setups get broken by this.

[jyknight]

So the problem Rust sees isn't that a ".1" was added to the version, but rather that the name was changed from "libLLVM-18-rust-1.78.0-nightly.so" to "libLLVM.so.18.1-rust-1.78.0-nightly". (that is: all the version info previously went into the library name which comes before ".so", and now goes into the library version which comes after ".so").

And issues with symlinks on Windows.

[tstellar]

@RalfJung Are you configuring LLVM with -DLLVM_VERSION_SUFFIX=-rust-1.78.0-nightly ?

[RalfJung]

So the problem Rust sees isn't that a ".1" was added to the version, but rather that the name was changed from "libLLVM-18-rust-1.78.0-nightly.so" to "libLLVM.so.18.1-rust-1.78.0-nightly". (that is: all the version info previously went into the library name which comes before ".so", and now goes into the library version which comes after ".so").

Ah, I didn't catch the shifted .so -- sounds right.

Are you configuring LLVM with -DLLVM_VERSION_SUFFIX=-rust-1.78.0-nightly ?

I have no idea, as I said I am working on a tool that fails to link now but have no direct contact with our LLVM stuff otherwise.^^ @nikic would know more.

At this point we seem to be on-track for fixing this so a revert would probably be extra work for us. But other users that tested rc3 may still be surprised by this I guess.

[nikic]

@RalfJung Are you configuring LLVM with -DLLVM_VERSION_SUFFIX=-rust-1.78.0-nightly ?

Yes.

So the problem Rust sees isn't that a ".1" was added to the version, but rather that the name was changed from "libLLVM-18-rust-1.78.0-nightly.so" to "libLLVM.so.18.1-rust-1.78.0-nightly". (that is: all the version info previously went into the library name which comes before ".so", and now goes into the library version which comes after ".so").

Right. The new scheme requires a symlink for linking, and rustup components currently do not support symlinks. But thankfully we can use a linker script instead of a symlink to sidestep the issue.