This nudges the Glibc modulemap just enough to get SwiftPM and later
targets building. Without it, Swift tries to import the signal hander
APIs through CDispatch instead of Glibc. CDispatch shouldn't be directly
imported, so recommending that is nonsensical.
This is not a full solution for all headers, but meant to perturb the
module machinery sufficiently that it pulls signal.h into glibc
correctly.
Works around:
```
Swift-Project/swiftpm/Sources/Basics/Cancellator.swift:79:24:
error: property '__sigaction_u' is not available due to missing import of defining module 'CDispatch' [#MemberImportVisibility]
```
This commit adds required conditional compilation blocks to enable bulding on
FreeBSD (tested on x86_64 FreeBSD 14.1-RELEASE-p6). Also implements FreeBSD
synchronization shims using `_umtx_op(2)`
This improves portability of the Swift toolchains by removing a usage of absolute path to Glibc.
The Glibc modulemap is now injected into the Glibc include path using LLVM VFS, so it can reference Glibc headers using relative paths. This already works for other Glibc headers (e.g. `assert.h`)
`assert.h` is missing from the modulemap, which causes clang to consider `assert.h` to be a part of the first module to include it. This causes issues in SwiftCompilerSources when we try to use classes coming from LLVM headers on Linux.
This migrates OpenBSD to use the single-header Glibc modulemap proposed
and implemented in #32404, and necessitates introducing some missing
headers for building Foundation added in #38341.
Additionally, incorporate nullability annotations in SwiftShims per
* Fix two issues with the SwiftGlibc module map.
The issues are:
- Today, some submodules in `SwiftGlibc` fail to provide definitions that
they should contain. As a consequence, Swift fails to import some code
that compiles correctly with standalone Clang. As just one example,
including `signal.h` should make the type `pid_t` available, but it
currently does not.
- `SwiftGlibc` is not compatible with the libc++ module map. Trying to
include libc++ headers in a C++ module imported into Swift results in an
error message about cyclic dependencies.
This change fixes both of these issues by making it so that `SwiftGlibc`
no actually longer defines a module map for the glibc headers but merely makes
all of the symbols from those headers available in a module that can be
imported into Swift. C / Objective-C / C++ code, on the other hand, will now
include the glibc headers texually.
For more context on the two issues and this fix, see this forum
discussion:
https://forums.swift.org/t/problems-with-swiftglibc-and-proposed-fix/37594
This change only modifies `glibc.modulemap.gyb` for the time being but
leaves `bionic.modulemap.gyb` and `libc-openbsd.modulemap.gyb` unchanged. The
intent is to fix these in the same way, but it will be easier to do this
in separate PRs that can be tested individually.
Co-authored-by: zoecarver <z.zoelec2@gmail.com>
Co-authored-by: Marcel Hlopko <hlopko@google.com>
This splits out the bionic modulemap from the glibc modulemap. They are
sufficiently different that the duplication is worth it. Furthermore,
it will enable properly identifying the libc on android. Once fully
detangled, this will enable the use of bionic on non-android platforms.
Reviewed the cases of Glibc where branching occurred and checked the
skipped headers against the Android NDK sysroot, and added the Android
check in the right places. This will give access to a lot more
functions from libc.
Unlike Darwin, on Linux when using functions from math.h the m library
needs to be added to the compilation. This should be explicit in the
module map, rather than being implicit in the driver.
Fixes SR-9198
Cross-compilation for multiple architectures & sdks require various
variables to be split to specify the arch/adk variant being focused on.
This change modifies various uses of the `SWIFT_SDK_${SDK}_PATH` to
`SWIFT_SDK_${SDK}_ARCH_${ARCH}`
sys/user.h provides definitions for registers. It would previously get
merged into the sys module which could result in it being multiply
included (as in the case of libdispatch). Add an explicit submodule.
Noticed when building libdispatch on Linux AArch64.
Things like: PthreadBarriers.swift:114:50: error: cannot convert value of type 'UnsafeMutablePointer<pthread_mutex_t>' (aka 'UnsafeMutablePointer<OpaquePointer>') to expected argument type 'UnsafeMutablePointer<pthread_mutex_t?>' (aka 'UnsafeMutablePointer<Optional<OpaquePointer>>')
on barrier.pointee.mutex . I need to do more research to understand this
