Skip to content

Conversation

@etcwilde
Copy link
Member

@etcwilde etcwilde commented Nov 5, 2025

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.

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.
@etcwilde etcwilde added the FreeBSD Platform: FreeBSD label Nov 5, 2025
@etcwilde
Copy link
Member Author

etcwilde commented Nov 5, 2025

@swift-ci please smoke test

@CodingCarpincho
Copy link

libxml2 is updated pretty frequently on FreeBSD as it is a user-installed package

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).

@etcwilde
Copy link
Member Author

etcwilde commented Nov 5, 2025

To be clear, the issue isn't that it's a user-installed package

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.

@etcwilde etcwilde moved this to In Progress in Swift on FreeBSD Nov 5, 2025
@CodingCarpincho
Copy link

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.

@jakepetroules
Copy link
Contributor

If/when Swift gets into official FreeBSD ports, presumably they can build their version with the LLVM_ENABLE_LIBXML2/DLLDB_ENABLE_LIBXML2 turned on.

@jakepetroules
Copy link
Contributor

Out of curiosity what does disabling this actually do? Does it remove any functionality? Should it be made conditional for FreeBSD only?

@etcwilde
Copy link
Member Author

etcwilde commented Nov 5, 2025

Honestly, I'm not entirely sure what a static linker does with XML support and I'm a little afraid to go digging.
For lldb, I believe it's for talking with remote targets (gdb-remote). @adrian-prantl, do you know how much of an effect this will have on the end-user experience?

@etcwilde
Copy link
Member Author

etcwilde commented Nov 5, 2025

Okay, I stand corrected, after a bit of digging, it looks like it's for the Windows manifest parsing on the lld side of things.

Copy link
Contributor

@JDevlieghere JDevlieghere left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

FreeBSD Platform: FreeBSD

Projects

Status: In Progress

Development

Successfully merging this pull request may close these issues.

4 participants