FreeBSD: Disable libxml2 in tools #85345
Conversation
|
@swift-ci please smoke test |
To be clear, the issue isn't that it's a user-installed package; it's that this particular package has a history of breaking ABI (and has in fact already done so during our process of working on this port). |
This package is particularly bad yes, but it's made it pretty clear that user-installed packages are unstable and do not adhere to the ABI stability rules that the libraries in the base installation do. |
|
Well, software libraries should generally maintain ABI stability, in my opinion. I recognize though that this is becoming less common. At the end of the day, if any of the libraries in ports breaks ABI, the FreeBSD ports maintainer(s) can just kick off a rebuild of any affected packages. We don't have that ability right now. |
|
If/when Swift gets into official FreeBSD ports, presumably they can build their version with the LLVM_ENABLE_LIBXML2/DLLDB_ENABLE_LIBXML2 turned on. |
|
Out of curiosity what does disabling this actually do? Does it remove any functionality? Should it be made conditional for FreeBSD only? |
|
Honestly, I'm not entirely sure what a static linker does with XML support and I'm a little afraid to go digging. |
|
Okay, I stand corrected, after a bit of digging, it looks like it's for the Windows manifest parsing on the |
JDevlieghere
left a comment
JDevlieghere
left a comment
There was a problem hiding this comment.
We need XML support in LLDB for the target.xml. I'm not sure if we fallback gracefully, I'm not aware of anyone building LLDB without XML support. If it works at all, it will regress performance because we would have to fall back to less efficient packets like qRegisterInfo.
This drops the dependency on the system libxml2 from the tools shipped in the toolchain bundle. libxml2 is disabled entirely for the LLVM/lld build, which uses it for processing the Windows manifest files. LLDB is changed to link against the static libxml2 built for the FoundationXML library. This is technically incorrect since the runtime may be cross-compiled for a different platform than what the toolchain is built to run on, but build-script is already mixing toolchain and runtime content in inconsistent ways, so this is no worse off than we are already. libxml2 is updated pretty frequently in inconsistent ways, resulting in failures to launch due to version incompatibilities.
etcwilde
force-pushed
the
ewilde/freebsd-disable-libxml2-in-tools
branch
from
e5f4b9e to
b6b152e
Compare
|
@swift-ci please smoke test |
JDevlieghere
left a comment
JDevlieghere
left a comment
There was a problem hiding this comment.
Thanks Evan! LGTM for LLDB.
4 participants
Removing the dependency on libxml2 from the tools. This is disabling it in LLVM, so lld won't depend on it, and in lldb.
libxml2 is updated pretty frequently on FreeBSD as it is a user-installed package. If folks have a different version of libxml2 installed from what is installed on the CI nodes, the resulting products won't launch.
Edit: Updated PR to statically link the runtime libxml2 static archive for FoundationXML into LLDB while leaving it disabled for lld, which uses it for the Windows manifest parsing.