[swift-corelibs-dev] Duplicate definition of va_list on Arm

[Pierre Habouzit]

> On Aug 19, 2016, at 10:35 PM, William Dillon <william at 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 <pierre at habouzit.net <mailto:pierre at 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 <william at housedillon.com <mailto:william at 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 <pierre at habouzit.net <mailto:pierre at 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 at swift.org <mailto:swift-corelibs-dev at 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 at swift.org <mailto:swift-corelibs-dev at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
>>>> 
>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20160819/17602007/attachment.html>