> On Aug 19, 2016, at 10:35 PM, William Dillon <will...@housedillon.com> wrote: > > 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.
That sounds like a bit of an extreme answer that won’t get you a lot of sympathy. 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. 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. 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. but right now you’re asking to break an architecture to support another, and that’s just not how porting works. -Pierre > >> On Aug 19, 2016, at 10:31 PM, Pierre Habouzit <pie...@habouzit.net >> <mailto:pie...@habouzit.net>> wrote: >> >> 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 >> <mailto: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 >>>> <mailto: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 <mailto: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 <mailto:swift-corelibs-dev@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev >>>>> <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
