compnerd
commented
6 years ago I believe that this may be caused by include paths not being setup for the dispatch internal headers. They are not generally made available, so we may have to introduce a `DISPATCH_SOURCE_DIR` cmake option to gain access to the header.
Environment
Swift-4.1-branch on Ubuntu Mate (ARMv7)Additional Detail from JIRA
| | | |------------------|-----------------| |Votes | 0 | |Component/s | Foundation | |Labels | Bug, armv7 | |Assignee | None | |Priority | Medium | md5: f07ee9baa995c7d95392133fee8c7b76Issue Description:
I'm opening this bug to document a minor issue noticed while compiling swift-4.1-branch on Ubuntu Mate on a RaspberryPi3.
Right now I've "solved" it redefining two missing types, but that's obviously not an ideal solution.
When the compilation reaches `CoreFoundation/RunLoop.subproj/CFRunLoop.c`, the compiler complains that it can't find definitions for `dispatch_runloop_handle_t` and `mach_port_t`, that are defined in libdispatch's `private.h`, a file that is included here:
```
#if HAS_DISPATCH && __has_include(\<dispatch/private.h>)
#include \<dispatch/private.h>
#elif HAS_DISPATCH
extern dispatch_queue_t _dispatch_runloop_root_queue_create_4CF(const char *_Nullable label, unsigned long flags);
extern mach_port_t _dispatch_runloop_root_queue_get_port_4CF(dispatch_queuet queue);
...
```
On Ubuntu Mate that `\_has_include(\<dispatch/private.h>)` is false and the second extern lacks a definition for its return type. Could this be the result of something happening somewhere in a makefile?