Skip to content

test: remove the expectation that dispatch is static #82162

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

compnerd
Copy link
Member

libdispatch will be built dynamically always as that is a C library and it does not make sense to have more than one copy in an address space, particularly if you have a Swift plugin hosted within a C program that has dispatch linked in.

libdispatch will be built dynamically always as that is a C library and
it does not make sense to have more than one copy in an address space,
particularly if you have a Swift plugin hosted within a C program that
has dispatch linked in.
@compnerd
Copy link
Member Author

@swift-ci please smoke test

@MaxDesiatov MaxDesiatov requested a review from al45tair June 11, 2025 08:43
@FranzBusch
Copy link
Member

@compnerd dispatch is still statically linked when passing —swift-static-stdlib even with this change right?

@compnerd
Copy link
Member Author

compnerd commented Jun 11, 2025

No, dispatch and BlocksRuntime would be dynamically linked. However, swiftDispatch would still be statically linked. That is the Swift side is statically linked, the C side is not.

@ktoso
Copy link
Contributor

ktoso commented Jun 11, 2025

I’m not sure that’s okey? Why do we think it’s ok to stop statically linking dispatch like this, won’t it defeat the “static link everything” server usecases?

@MaxDesiatov
Copy link
Contributor

MaxDesiatov commented Jun 11, 2025

No, dispatch and BlocksRuntime would be dynamically linked.

Would that be the case even with the Swift SDK for static Linux?

@compnerd
Copy link
Member Author

No, dispatch and BlocksRuntime would be dynamically linked.

Would that be the case even with the Swift SDK for static Linux?

Yes, it would be the case for the static Linux SDK as well. These are C libraries and if you have hosted Swift code (e.g. a plugin), you would have multiple copies of dispatch and BlocksRuntime which is wrong. This is akin to having multiple Swift runtimes which yields subtle correctness issues.

@compnerd
Copy link
Member Author

BTW, this change itself is a no-op: it doesn't change anything but the test cases to remove the special lit expansion (which really shouldn't matter). Everything that this is intended to do is still possible (i.e. if you build your own libdispatch statically and adjust the linker search path, adjust the clang importer, adjust the headers, adjust the flags, adjust clang, the, yes, it would still statically link). We don't do any of that currently, and the dispatch headers are not setup for proper static linking, clang is not setup for proper static/dynamic linking, and the ClangImporter and swift-driver are not setup for this to be handled properly so this just happens to work by sheer luck on some platforms.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants