Fix va_list on arm, and 32-bit CGFloat.NativeType #603
Conversation
|
Is there no better way to deal with the |
|
@swift-ci please smoke test |
|
I absolutely agree. I haven't found one. I don't know why the GCC version (installed in /usr/include/stdio.h) isn't respecting the |
|
More context/discussion available here #399 |
|
The header
|
|
I see what you're looking at, too. What I mean by not respecting it is that if I try to ensure that, for example, |
|
Header search paths are incorrect is my guess. Its probably that the resource dir is being mis-ordered. |
|
That's a great find! I'd love to use that as the seed for a proper fix. I don't know where the resource dir is configured, though. Do you have a hint? |
|
You should be able to use |
|
What seems strange to me is that the clang 3.6 behavior on x86-64 linux: Is identical to the clang 3.6 behavior on armv7l linux: I don't follow why there isn't a problem with va_list on x86-64 linux when there is on arm. I think I see what you're getting at with the include search path when I compare clang 3.6 to gcc, however, as the clang 3.6 search order is: whereas GCC is: I bet had Doesn't swift get compiled with its own clang 3.9 compiler? |
|
@hpux735 Could that be a bug? Aren't the clang headers supposed to always come first? Trying the same on a mac (don't have an x86 linux box available, but it seems to be the same: http://stackoverflow.com/a/33485647): Otherwise, yeah, you'll get redefinition issues. Hmmm... interesting. I've seen the issue crop up occasionally over the years, but you'd think someone would have done something by now. |
|
Right, I'd think it would be, too. I have a nagging feeling it's like that for a reason (perhaps better source compatibility with GCC?), but I just don't know. Either way, for the moment at least, we just have to deal with it. :) |
|
I'm not sure the search order is the problem. My cross-compile sysroot doesn't even have a
Urgh. Shot in the dark, maybe @ddunbar, as a former clangster with an interest in cross-compilation, can help? This might be helpful, from GCC's stdarg.h: |
|
32-bit CGFloat.NativeType was addressed by #632, so this part of the PR can be removed. |
|
So, two things now:
|
|
I'm not aware of a consensus on stdio.h. In libdispatch, I recall the patch having been applied. Here, however, it's still necessary. I haven't found a resolution to it via any other method to date. |
|
@hpux735 what's going on with this PR? |
|
I haven't had any time to work on it. I'm still not aware of any alternate means for moving past it. Subsequently, I've made a fork of Swift at swift-arm that has the patch. A similar PR was accepted over on the dispatch side. It would be great if we could merge this, because this PR is the majority of changes that justify the swift-arm fork. |
|
I was playing around attempting to get swift running on an ODROID-C2 which is arm64 running a Debian derivative, and I've run into this (or a similar) issue - unfortunately, the "easy" fix above, does not work with arm64 and linux. Unfortunately, I don't know enough about arm64 to know why. https://bugs.swift.org/browse/SR-2239 seems to be similar, if not the same issue. |
|
This pull request has gone stale, closing. |
This PR addresses a few problems that CF has accumulated on arm-linux platforms. One obviates the need for #399 by @karwa (and makes it hopefully more palatable). Also, a more recent addition of an import of stdio.h expresses a similar issue with the redefinition of va_list.
Another issue addressed with this PR is the fact that CGFloat.NativeType is now Float on32-bit systems and Double on 64-bit, thanks to #585 . There is a function in NSGeometry that assumed that CGFloat.native would always return Double. It's intermediate variables are now CGFloat.NativeType.
Finally, NSXML has a constant bitfield assignment that has been mentioned is redundant (see 998d5c0#commitcomment-18697699 ), but causes issues when used with signed 32-bit types. I've removed that.