<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><div><blockquote type="cite" class=""><div class="">On Aug 19, 2016, at 10:35 PM, William Dillon <<a href="mailto:william@housedillon.com" class="">william@housedillon.com</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="">Ok then. At this point I suppose I'm looking at maintaining a fork of libdispatch. I can't think of any other solutions that make sense.</div></div></blockquote><div><br class=""></div><div>That sounds like a bit of an extreme answer that won’t get you a lot of sympathy.<div class=""><br class=""></div><div class="">The problem at the heart is that glibc doesn’t have a consistent way of defining things depending on the architecture, and doesn’t work well with modules, which will break swift all over the place. macOS went through several iterations to have its own Libc work well with modules. It has nothing to do with dispatch for real.</div><div class=""><br class=""></div><div class="">The way to address that is to either get glibc to change (good luck with that, I used to co maintain it in Debian a lifetime ago, and let’s say I doubt you will get a lot of traction here), or you work with the swift toolchain to try to find a solution to overlay on top of glibc headers so that these kind of things have a sane cross-architecture solution.</div><div class=""><br class=""></div><div class="">gcc used to have what they called “fixed headers” where they had this tool to fix some mistakes that caused system headers to be broken, maybe swift needs to have something like that until the underlying projects slowly get fixed.</div><div class=""><br class=""></div><div class="">but right now you’re asking to break an architecture to support another, and that’s just not how porting works.</div><div class=""><br class=""></div><div class=""><br class=""><div class="">-Pierre</div></div></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 19, 2016, at 10:31 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=utf-8" class=""><div dir="auto" class=""><div class=""><div style="direction: inherit;" class="">Dispatch/dispatch.h is a public header. So not really. </div><br class="">-Pierre on his iPhone</div><div class=""><br class="">On Aug 19, 2016, at 8:41 PM, William Dillon <<a href="mailto:william@housedillon.com" class="">william@housedillon.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class="">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 class=""><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></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></body></html>