Skip to content

build: various adjustments for the runtime libraries #874

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 3 commits into
base: main
Choose a base branch
from

Conversation

compnerd
Copy link
Member

Adjust the build in three specific manners:

  1. hoist BlocksRuntime inclusion to the top level, it is not part of libdispatch
  2. only support a shared library build of libdispatch as the project conflates libdispatch and libclosure, and BUILD_SHARED_LIBS only permits us to globally control that behaviour
  3. adjust the libclosure build to include the necessary flags to support building against a static libclosure

After a side discussion between @rokhinip, @mikeash, @akmorrison, and myself (@compnerd), we decided that we should only support a dynamically linked libdispatch for the C portion of the runtime. While we have not yet decided on the direction for libclosure, in order to support the build of a static and dynamic libclosure, we pin the libdispatch build to a shared only build rather than just letting the build system control this via the BUILD_SHARED_LIBS global flag.

compnerd added 3 commits May 16, 2025 08:40
Move the subdirectory recursion for the BlocksRuntime to the top level
as this is a separate target entity.
As per the discussion with @rokhinip, @mikeash, and @compnerd, always
build libdispatch in shared mode. The rationale for this is the
following:

  If someone does a `-static-stdlib` build of Swift code as a plugin
  which is hosted in a C/C++ environment, you cannot have two dispatch
  implementations to run this. You need a single one, and because the
  host environment may be dynamically linked - you need to dynamically
  link libdispatch (the C portions).

This prepares us to be able to build the rest of the dispatch code
(swiftDispatch) both statically and dynamically. Until we have a
resolution on BlocksRuntime, build the library both ways. Note that in
order to use a static copy of BlocksRuntime, `-static-libclosure` must
be used at *compile* time.
While we are still undecided on the state of libclosure (whether it
should be supported as a dynamic-only linked dependency or whether we
should support statically linking against the library), tweak the build
to support the static builds on Windows.
@compnerd
Copy link
Member Author

@swift-ci please test

@compnerd
Copy link
Member Author

@swift-ci please test Linux platform

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.

1 participant