Open aaronmondal opened 1 year ago
Could you explain why this could manifest as issues in LTO? It's not immediately obvious to me having a symbol that isn't defined everywhere (HMI
in Mesa) in linker script can cause troubles.
I implemented --no-undefined-version
as a hard error at first. But testing with real-world program revealed that that caused too many build failures. We could blame erroneous user-supplied version scripts, but in reality, suddenly starting handling such version scripts as hard errors is too disruptive. So I made it a soft error. We might want to change that in future, but I believe it's too early to do so.
Yeah, from my experience testing LLVM 16 in Gentoo --no-undefined-version breaks too many packages. In an ideal world it would be hard error but it's very common currently.
In lld this is flagged as an error, and the default recently changed in https://reviews.llvm.org/D135402.
In comparison, mold's current behavior is a warning:
I've now seen several issues in projects where people think using mold instead of lld "fixes" their issue, when its actually just that mold's warnings are easier to overlook than a hard error. (e.g. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8437 and https://github.com/llvm/llvm-project/issues/60859)
Down the line this then manifests in issues where users suddenly have issues with e.g. LTO and don't know what's causing it.
I think it might be a good idea to also make
--no-undefined-version
violations a hard error in mold so that users don't get confused. Forcing people to fix their linker scripts seems like the right way to go.cc @MaskRay