Hi all,
In corelibs-foundation project we've been using a patch based on Fix building on linux (arm) by karwa · Pull Request #399 · apple/swift-corelibs-foundation · GitHub 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: Fix building on armv7 by hpux735 · Pull Request #155 · apple/swift-corelibs-libdispatch · GitHub
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
One of the challenges we have in removing imports in public headers is that other projects are importing those headers transitively. Someone else may be assuming they get stdio.h by importing CoreFoundation.h or dispatch.h, and using something from that header.
- Tony
···
On Aug 19, 2016, at 11:53 AM, William Dillon via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
Hi all,
In corelibs-foundation project we've been using a patch based on Fix building on linux (arm) by karwa · Pull Request #399 · apple/swift-corelibs-foundation · GitHub 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: Fix building on armv7 by hpux735 · Pull Request #155 · apple/swift-corelibs-libdispatch · GitHub
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
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
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> wrote:
Hi all,
In corelibs-foundation project we've been using a patch based on Fix building on linux (arm) by karwa · Pull Request #399 · apple/swift-corelibs-foundation · GitHub 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: Fix building on armv7 by hpux735 · Pull Request #155 · apple/swift-corelibs-libdispatch · GitHub
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
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
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@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 Fix building on linux (arm) by karwa · Pull Request #399 · apple/swift-corelibs-foundation · GitHub 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: Fix building on armv7 by hpux735 · Pull Request #155 · apple/swift-corelibs-libdispatch · GitHub
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
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@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@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> wrote:
Hi all,
In corelibs-foundation project we've been using a patch based on Fix building on linux (arm) by karwa · Pull Request #399 · apple/swift-corelibs-foundation · GitHub 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: Fix building on armv7 by hpux735 · Pull Request #155 · apple/swift-corelibs-libdispatch · GitHub
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
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
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.
···
On Aug 19, 2016, at 10:31 PM, Pierre Habouzit <pierre@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@housedillon.com <mailto:william@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@habouzit.net <mailto:pierre@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 Fix building on linux (arm) by karwa · Pull Request #399 · apple/swift-corelibs-foundation · GitHub 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: Fix building on armv7 by hpux735 · Pull Request #155 · apple/swift-corelibs-libdispatch · GitHub
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
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:35 PM, William Dillon <william@housedillon.com> wrote:
On Aug 19, 2016, at 10:31 PM, Pierre Habouzit <pierre@habouzit.net <mailto:pierre@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@housedillon.com <mailto:william@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@habouzit.net <mailto:pierre@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 Fix building on linux (arm) by karwa · Pull Request #399 · apple/swift-corelibs-foundation · GitHub 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: Fix building on armv7 by hpux735 · Pull Request #155 · apple/swift-corelibs-libdispatch · GitHub
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