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 > <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 > <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
