Demote --no-undefined-version to warning

[nikic]

LLVM 16 enabled --no-undefined-version by default in https://reviews.llvm.org/D135402. This caused wide-spread breakage, including in LLVM itself.

We should consider demoting this to a warning, at least for the LLVM 16 release. This will make people aware that there is an issue, without breaking builds.

[nikic]

@MaskRay Any thoughts on this? Would it make sense to make this a warning first, before making it a hard error?

[MaskRay]

We should quantify "wide-spread breakage". As I know Gentoo sees issues from ~10 packages: gentoo/gentoo#29097 I have reported issues in their issue trackers or fixed the issue myself.

If the issue is using ld.lld with old versions of these packages, changing error to warn for just release/16.x is fine.
You can cherry pick https://github.com/MaskRay/llvm-project/tree/no-undefined-version into release/16.x.
There is no sufficient evidence to change the main branch decision, though.

[llvmbot]

@llvm/issue-subscribers-lld-elf

[nikic]

/branch MaskRay/llvm-project/no-undefined-version

[llvmbot]

/pull-request llvm/llvm-project-release-prs#347

[nikic]

We should quantify "wide-spread breakage". As I know Gentoo sees issues from ~10 packages: gentoo/gentoo#29097 I have reported issues in their issue trackers or fixed the issue myself.

Also breaks Rust on two different levels.

If the issue is using ld.lld with old versions of these packages, changing error to warn for just release/16.x is fine. You can cherry pick https://github.com/MaskRay/llvm-project/tree/no-undefined-version into release/16.x. There is no sufficient evidence to change the main branch decision, though.

I think that's fine. The only problem is that this went directly to an error. If there is a warning cycle in between, it should be okay.