<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.&nbsp;</div><br>-Pierre on his iPhone</div><div><br>On Aug 19, 2016, at 8:41 PM, William Dillon &lt;<a href="mailto:william@housedillon.com">william@housedillon.com</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=us-ascii">True enough. &nbsp;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 &lt;<a href="mailto:pierre@habouzit.net" class="">pierre@habouzit.net</a>&gt; 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 &lt;<a href="mailto:swift-corelibs-dev@swift.org" class="">swift-corelibs-dev@swift.org</a>&gt; 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&nbsp;<a href="https://github.com/apple/swift-corelibs-foundation/pull/399/files" class="">https://github.com/apple/swift-corelibs-foundation/pull/399/files</a>&nbsp;for quite some time (summary: remove #include &lt;stdio.h&gt;). &nbsp;The PR hasn't gotten any where for various reasons. &nbsp;Currently, I've gotten libdispatch working on arm, but it requires a fix that's essentially identical. &nbsp;It is part of a PR available here:&nbsp;<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. &nbsp;What exactly is stdio.h bringing in? &nbsp;I realize the comment identifies __off_t, but at least on arm that's being provided elsewhere. &nbsp;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>