Dispatch/dispatch.h is a public header. So not really. -Pierre on his iPhone
> On Aug 19, 2016, at 8:41 PM, William Dillon <will...@housedillon.com> wrote: > > True enough. In that case, would be acceptable to match by architecture and > skip the import on arm? > >> On Aug 19, 2016, at 5:56 PM, Pierre Habouzit <pie...@habouzit.net> wrote: >> >> the include was added to dispatch specifically to allow dispatch_io to build >> on intel so your patch I think would break Intel. >> >> I think the general problem is likely that glibc is not module friendly >> today. >> >> -Pierre >> >>> On Aug 19, 2016, at 11:53 AM, William Dillon via swift-corelibs-dev >>> <swift-corelibs-dev@swift.org> wrote: >>> >>> Hi all, >>> >>> In corelibs-foundation project we've been using a patch based on >>> https://github.com/apple/swift-corelibs-foundation/pull/399/files for quite >>> some time (summary: remove #include <stdio.h>). The PR hasn't gotten any >>> where for various reasons. Currently, I've gotten libdispatch working on >>> arm, but it requires a fix that's essentially identical. It is part of a >>> PR available here: >>> https://github.com/apple/swift-corelibs-libdispatch/pull/155 >>> >>> I'd like to get this moving forward in both cases, and I'd like to bring it >>> to the list. What exactly is stdio.h bringing in? I realize the comment >>> identifies __off_t, but at least on arm that's being provided elsewhere. >>> Furthermore, __off_t is defined in several places. >>> >>> Are there any suggestions for what a satisfactory solution would be to >>> address the duplicate definition of va_list on arm that does not negatively >>> impact other platforms? >>> >>> Thanks, >>> - Will >>> _______________________________________________ >>> swift-corelibs-dev mailing list >>> swift-corelibs-dev@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev >> >
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev