-
Notifications
You must be signed in to change notification settings - Fork 10.5k
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
base: main
Are you sure you want to change the base?
Conversation
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.
@swift-ci please smoke test |
@compnerd dispatch is still statically linked when passing |
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. |
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? |
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. |
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. |
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.