<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><div style="direction: inherit;">Dispatch/dispatch.h is a public header. So not really. </div><br>-Pierre on his iPhone</div><div><br>On Aug 19, 2016, at 8:41 PM, William Dillon <<a href="mailto:william@housedillon.com">william@housedillon.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=us-ascii">True enough. In that case, would be acceptable to match by architecture and skip the import on arm?<div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Aug 19, 2016, at 5:56 PM, Pierre Habouzit <<a href="mailto:pierre@habouzit.net" class="">pierre@habouzit.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">the include was added to dispatch specifically to allow dispatch_io to build on intel so your patch I think would break Intel.<div class=""><br class=""></div><div class="">I think the general problem is likely that glibc is not module friendly today.</div><div class=""><br class=""><div class="">
-Pierre
</div>
<br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 19, 2016, at 11:53 AM, William Dillon via swift-corelibs-dev <<a href="mailto:swift-corelibs-dev@swift.org" class="">swift-corelibs-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi all,<div class=""><br class=""></div><div class="">In corelibs-foundation project we've been using a patch based on <a href="https://github.com/apple/swift-corelibs-foundation/pull/399/files" class="">https://github.com/apple/swift-corelibs-foundation/pull/399/files</a> 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: <a href="https://github.com/apple/swift-corelibs-libdispatch/pull/155" class="">https://github.com/apple/swift-corelibs-libdispatch/pull/155</a></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">- Will</div></div>_______________________________________________<br class="">swift-corelibs-dev mailing list<br class=""><a href="mailto:swift-corelibs-dev@swift.org" class="">swift-corelibs-dev@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-corelibs-dev" class="">https://lists.swift.org/mailman/listinfo/swift-corelibs-dev</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></blockquote></body></html>