Description
| Previous ID | SR-2309 |
| Radar | None |
| Original Reporter | dgrove-oss (JIRA User) |
| Type | Bug |
| Status | Resolved |
| Resolution | Done |
Additional Detail from JIRA
| Votes | 0 |
| Component/s | libdispatch |
| Labels | Bug, Linux |
| Assignee | dgrove-oss (JIRA) |
| Priority | Medium |
md5: f2c4c608d93c907594116fa473b1e39e
Issue Description:
libdispatch uses the blocks language feature and therefore has a runtime dependency on libBlocksRuntime.so As we enable libdispatch by default on Linux and start depending on it in Foundation, xctest, etc. we need to decide how best to satisfy this dependency.
There are thee obvious options:
-
Rely on the end-user installing libblocksruntime on their system via apt get (ie, add as a general pre-req for Swift).
-
Embed the blocks runtime code into libdispatch.so (as is already done with Foundation).
-
Build one copy of the blocks runtime as part of building the Swift toolchain and have both dispatch and Foundation link to it.
Ultimately, the third option is probably the best final solution. It minimizes duplicated code and also would allow us to develop a single variant of the blocks runtime that implemented Swift retain/release operations and and avoid needing to "wrap" Swift blocks using @convention(block) when calling into C-code that was compiled to expect C blocks.
The first solution is trivial, but requires additional system libraries to be installed and thus creates a (small) additional barrier to entry.
The second solution is straightforward and can be implemented entirely within libdispatch by copying in the code from compiler-rt/lib/BlocksRuntime and tweaking the libdispatch build.