I’m trying to fix Foundation on OSX (or am I doing something wrong? I was surprised to find it didn’t build)
I’ve run in to a problem, though: swift is telling me that certain APIs are not available:
Foundation/NSNumberFormatter.swift:19:70: error: 'ordinalStyle' is only available on OS X 10.11 or newer
internal let kCFNumberFormatterOrdinalStyle = CFNumberFormatterStyle.ordinalStyle
^
Foundation/NSNumberFormatter.swift:19:70: note: add @available attribute to enclosing let
internal let kCFNumberFormatterOrdinalStyle = CFNumberFormatterStyle.ordinalStyle
^
That’s because the CoreFoundation headers have availability declarations on them.
It obviously doesn’t make sense for us to keep them (and for the resulting swift Foundation project to inherit them), because we’re building a toolchain and defining all of those symbols, not linking against the system versions.
So in order to build CoreFoundation/Foundation for OSX, we’d need to remove these declarations from the headers. Is there any problem with that? Are they synced to anything at Apple HQ?
The Swift compiler is correct here - the CF header has an availability attribute, but the Foundation symbol doesn’t. Either the Foundation symbol needs to become less available, or the CF one needs to become more available.
I bypassed it by removing the restrictions from CF, but then I had a problem at link time: CFRuntime has hardcoded symbols which require the module name to be “SwiftFoundation”, but it’s defined (right at the top of build.py) as being “Foundation” (and it’s always been like that since the first commit). So I don’t know what’s correct - the hardcoded symbols, which say it’s ‘SwiftFoundation’, or the build script, which has always called it just ‘Foundation’. I don’t see how it ever compiled and linked on OSX.
That’s not all, either - there’s a clang bug (since version 5 apparently) which causes it to emit calls to its own ___udivti3 builtin which it can’t resolve, so you need to add a clang-specific hack to disable 128-bit division in CFBigNum or it also won't link.
After you do that, you can finally create libFoundation.dylib. Unfortunately, I tried to build xctest afterwards. If you called the module ‘Foundation’, it’ll fire up xcodebuild, which fails with those missing symbols from CFRuntime - this time it wants them to be called “SwiftFoundation”. So am I supposed to build it as SwiftFoundation? Okay, so I did that.
I don’t remember if xctest compiled fully (I don’t think it did...), then I disabled it, and tried to build swiftpm instead. I managed to get most of the way through that, but then it failed while trying to link ‘swift_build’ because the link directory <foundation build dir>/Foundation didn’t exist (of course it doesn't; it’s called SwiftFoundation now!).
So now I’m just feeling like I opened a can of worms.
···
On 18 May 2016, at 15:56, Philippe Hausler <phausler@apple.com> wrote:
We are keeping the CoreFoundation sources in sync with the one that is skipped with your SDK and the one running on your system.
What version of Mac OS X are you running? What version of the SDK do you have? I have a feeling that a combination of those two may be the reason for those errors.
Sent from my iPhone
On May 18, 2016, at 4:44 AM, Karl via swift-dev <swift-dev@swift.org> wrote:
I’m trying to fix Foundation on OSX (or am I doing something wrong? I was surprised to find it didn’t build)
I’ve run in to a problem, though: swift is telling me that certain APIs are not available:
Foundation/NSNumberFormatter.swift:19:70: error: 'ordinalStyle' is only available on OS X 10.11 or newer
internal let kCFNumberFormatterOrdinalStyle = CFNumberFormatterStyle.ordinalStyle
^
Foundation/NSNumberFormatter.swift:19:70: note: add @available attribute to enclosing let
internal let kCFNumberFormatterOrdinalStyle = CFNumberFormatterStyle.ordinalStyle
^
That’s because the CoreFoundation headers have availability declarations on them.
It obviously doesn’t make sense for us to keep them (and for the resulting swift Foundation project to inherit them), because we’re building a toolchain and defining all of those symbols, not linking against the system versions.
So in order to build CoreFoundation/Foundation for OSX, we’d need to remove these declarations from the headers. Is there any problem with that? Are they synced to anything at Apple HQ?
To clarify: xctest tries to build Foundation using xcodebuild. Actually, I wonder why it didn’t use xcodebuild the first time.
Maybe it should. Maybe that’s the way out of this.
···
On 18 May 2016, at 16:21, Karl <raziel.im+swift-users@gmail.com> wrote:
OSX 10.11.4, latest Xcode and SDKs.
The Swift compiler is correct here - the CF header has an availability attribute, but the Foundation symbol doesn’t. Either the Foundation symbol needs to become less available, or the CF one needs to become more available.
I bypassed it by removing the restrictions from CF, but then I had a problem at link time: CFRuntime has hardcoded symbols which require the module name to be “SwiftFoundation”, but it’s defined (right at the top of build.py) as being “Foundation” (and it’s always been like that since the first commit). So I don’t know what’s correct - the hardcoded symbols, which say it’s ‘SwiftFoundation’, or the build script, which has always called it just ‘Foundation’. I don’t see how it ever compiled and linked on OSX.
That’s not all, either - there’s a clang bug (since version 5 apparently) which causes it to emit calls to its own ___udivti3 builtin which it can’t resolve, so you need to add a clang-specific hack to disable 128-bit division in CFBigNum or it also won't link.
After you do that, you can finally create libFoundation.dylib. Unfortunately, I tried to build xctest afterwards. If you called the module ‘Foundation’, it’ll fire up xcodebuild, which fails with those missing symbols from CFRuntime - this time it wants them to be called “SwiftFoundation”. So am I supposed to build it as SwiftFoundation? Okay, so I did that.
I don’t remember if xctest compiled fully (I don’t think it did...), then I disabled it, and tried to build swiftpm instead. I managed to get most of the way through that, but then it failed while trying to link ‘swift_build’ because the link directory <foundation build dir>/Foundation didn’t exist (of course it doesn't; it’s called SwiftFoundation now!).
So now I’m just feeling like I opened a can of worms.
On 18 May 2016, at 15:56, Philippe Hausler <phausler@apple.com> wrote:
We are keeping the CoreFoundation sources in sync with the one that is skipped with your SDK and the one running on your system.
What version of Mac OS X are you running? What version of the SDK do you have? I have a feeling that a combination of those two may be the reason for those errors.
Sent from my iPhone
On May 18, 2016, at 4:44 AM, Karl via swift-dev <swift-dev@swift.org> wrote:
I’m trying to fix Foundation on OSX (or am I doing something wrong? I was surprised to find it didn’t build)
I’ve run in to a problem, though: swift is telling me that certain APIs are not available:
Foundation/NSNumberFormatter.swift:19:70: error: 'ordinalStyle' is only available on OS X 10.11 or newer
internal let kCFNumberFormatterOrdinalStyle = CFNumberFormatterStyle.ordinalStyle
^
Foundation/NSNumberFormatter.swift:19:70: note: add @available attribute to enclosing let
internal let kCFNumberFormatterOrdinalStyle = CFNumberFormatterStyle.ordinalStyle
^
That’s because the CoreFoundation headers have availability declarations on them.
It obviously doesn’t make sense for us to keep them (and for the resulting swift Foundation project to inherit them), because we’re building a toolchain and defining all of those symbols, not linking against the system versions.
So in order to build CoreFoundation/Foundation for OSX, we’d need to remove these declarations from the headers. Is there any problem with that? Are they synced to anything at Apple HQ?
Yea, the python build scripts only work on Linux. Before the initial drop I was tinkering with making it build both but the Xcode project was just simpler and easier to maintain. Either use xcodebuild or use the Xcode IDE instead of the ninja builders.
It might be nice one day to unify the Linux and Darwin builds. Per the name of Foundation versus SwiftFoundation it sidesteps the potentials of getting confused with the system version (since they are not replaceable due to object layouts among other things).
···
Sent from my iPhone
On May 18, 2016, at 7:24 AM, Karl <razielim@gmail.com> wrote:
To clarify: xctest tries to build Foundation using xcodebuild. Actually, I wonder why it didn’t use xcodebuild the first time.
Maybe it should. Maybe that’s the way out of this.
On 18 May 2016, at 16:21, Karl <raziel.im+swift-users@gmail.com> wrote:
OSX 10.11.4, latest Xcode and SDKs.
The Swift compiler is correct here - the CF header has an availability attribute, but the Foundation symbol doesn’t. Either the Foundation symbol needs to become less available, or the CF one needs to become more available.
I bypassed it by removing the restrictions from CF, but then I had a problem at link time: CFRuntime has hardcoded symbols which require the module name to be “SwiftFoundation”, but it’s defined (right at the top of build.py) as being “Foundation” (and it’s always been like that since the first commit). So I don’t know what’s correct - the hardcoded symbols, which say it’s ‘SwiftFoundation’, or the build script, which has always called it just ‘Foundation’. I don’t see how it ever compiled and linked on OSX.
That’s not all, either - there’s a clang bug (since version 5 apparently) which causes it to emit calls to its own ___udivti3 builtin which it can’t resolve, so you need to add a clang-specific hack to disable 128-bit division in CFBigNum or it also won't link.
After you do that, you can finally create libFoundation.dylib. Unfortunately, I tried to build xctest afterwards. If you called the module ‘Foundation’, it’ll fire up xcodebuild, which fails with those missing symbols from CFRuntime - this time it wants them to be called “SwiftFoundation”. So am I supposed to build it as SwiftFoundation? Okay, so I did that.
I don’t remember if xctest compiled fully (I don’t think it did...), then I disabled it, and tried to build swiftpm instead. I managed to get most of the way through that, but then it failed while trying to link ‘swift_build’ because the link directory <foundation build dir>/Foundation didn’t exist (of course it doesn't; it’s called SwiftFoundation now!).
So now I’m just feeling like I opened a can of worms.
On 18 May 2016, at 15:56, Philippe Hausler <phausler@apple.com> wrote:
We are keeping the CoreFoundation sources in sync with the one that is skipped with your SDK and the one running on your system.
What version of Mac OS X are you running? What version of the SDK do you have? I have a feeling that a combination of those two may be the reason for those errors.
Sent from my iPhone
On May 18, 2016, at 4:44 AM, Karl via swift-dev <swift-dev@swift.org> wrote:
I’m trying to fix Foundation on OSX (or am I doing something wrong? I was surprised to find it didn’t build)
I’ve run in to a problem, though: swift is telling me that certain APIs are not available:
Foundation/NSNumberFormatter.swift:19:70: error: 'ordinalStyle' is only available on OS X 10.11 or newer
internal let kCFNumberFormatterOrdinalStyle = CFNumberFormatterStyle.ordinalStyle
^
Foundation/NSNumberFormatter.swift:19:70: note: add @available attribute to enclosing let
internal let kCFNumberFormatterOrdinalStyle = CFNumberFormatterStyle.ordinalStyle
^
That’s because the CoreFoundation headers have availability declarations on them.
It obviously doesn’t make sense for us to keep them (and for the resulting swift Foundation project to inherit them), because we’re building a toolchain and defining all of those symbols, not linking against the system versions.
So in order to build CoreFoundation/Foundation for OSX, we’d need to remove these declarations from the headers. Is there any problem with that? Are they synced to anything at Apple HQ?
Yeah it all makes much more sense now. I was so stuck in the terminal I completely forgot there even was an Xcode project.
So I’ll submit a patch making the python script farm out to xcodebuild instead of trying to configure a Mac.
···
On 18 May 2016, at 16:35, Philippe Hausler <phausler@apple.com> wrote:
Yea, the python build scripts only work on Linux. Before the initial drop I was tinkering with making it build both but the Xcode project was just simpler and easier to maintain. Either use xcodebuild or use the Xcode IDE instead of the ninja builders.
It might be nice one day to unify the Linux and Darwin builds. Per the name of Foundation versus SwiftFoundation it sidesteps the potentials of getting confused with the system version (since they are not replaceable due to object layouts among other things).
Sent from my iPhone
On May 18, 2016, at 7:24 AM, Karl <razielim@gmail.com> wrote:
To clarify: xctest tries to build Foundation using xcodebuild. Actually, I wonder why it didn’t use xcodebuild the first time.
Maybe it should. Maybe that’s the way out of this.
On 18 May 2016, at 16:21, Karl <raziel.im+swift-users@gmail.com> wrote:
OSX 10.11.4, latest Xcode and SDKs.
The Swift compiler is correct here - the CF header has an availability attribute, but the Foundation symbol doesn’t. Either the Foundation symbol needs to become less available, or the CF one needs to become more available.
I bypassed it by removing the restrictions from CF, but then I had a problem at link time: CFRuntime has hardcoded symbols which require the module name to be “SwiftFoundation”, but it’s defined (right at the top of build.py) as being “Foundation” (and it’s always been like that since the first commit). So I don’t know what’s correct - the hardcoded symbols, which say it’s ‘SwiftFoundation’, or the build script, which has always called it just ‘Foundation’. I don’t see how it ever compiled and linked on OSX.
That’s not all, either - there’s a clang bug (since version 5 apparently) which causes it to emit calls to its own ___udivti3 builtin which it can’t resolve, so you need to add a clang-specific hack to disable 128-bit division in CFBigNum or it also won't link.
After you do that, you can finally create libFoundation.dylib. Unfortunately, I tried to build xctest afterwards. If you called the module ‘Foundation’, it’ll fire up xcodebuild, which fails with those missing symbols from CFRuntime - this time it wants them to be called “SwiftFoundation”. So am I supposed to build it as SwiftFoundation? Okay, so I did that.
I don’t remember if xctest compiled fully (I don’t think it did...), then I disabled it, and tried to build swiftpm instead. I managed to get most of the way through that, but then it failed while trying to link ‘swift_build’ because the link directory <foundation build dir>/Foundation didn’t exist (of course it doesn't; it’s called SwiftFoundation now!).
So now I’m just feeling like I opened a can of worms.
On 18 May 2016, at 15:56, Philippe Hausler <phausler@apple.com> wrote:
We are keeping the CoreFoundation sources in sync with the one that is skipped with your SDK and the one running on your system.
What version of Mac OS X are you running? What version of the SDK do you have? I have a feeling that a combination of those two may be the reason for those errors.
Sent from my iPhone
On May 18, 2016, at 4:44 AM, Karl via swift-dev <swift-dev@swift.org> wrote:
I’m trying to fix Foundation on OSX (or am I doing something wrong? I was surprised to find it didn’t build)
I’ve run in to a problem, though: swift is telling me that certain APIs are not available:
Foundation/NSNumberFormatter.swift:19:70: error: 'ordinalStyle' is only available on OS X 10.11 or newer
internal let kCFNumberFormatterOrdinalStyle = CFNumberFormatterStyle.ordinalStyle
^
Foundation/NSNumberFormatter.swift:19:70: note: add @available attribute to enclosing let
internal let kCFNumberFormatterOrdinalStyle = CFNumberFormatterStyle.ordinalStyle
^
That’s because the CoreFoundation headers have availability declarations on them.
It obviously doesn’t make sense for us to keep them (and for the resulting swift Foundation project to inherit them), because we’re building a toolchain and defining all of those symbols, not linking against the system versions.
So in order to build CoreFoundation/Foundation for OSX, we’d need to remove these declarations from the headers. Is there any problem with that? Are they synced to anything at Apple HQ?
Actually, on closer look I’d like to do it the other way around and clean up my changes and integrate the python script in to the build script for OSX.
The reason is that it produces a dylib, which is easier to install in an xctoolchain. I tried putting the .framework in the toolchain’s /System/Library/Frameworks, but I wasn’t able to import it.
Also, it would be a good idea to rename ‘SwiftFoundation’. I understand why you’d want to give it a separate name from the first-party one as it doesn’t support Objective-C, but ‘SwiftFoundation’ is literally the only other name it can’t have. Like this, you’re not able to have the first-party platform overlay cohabiting in the lib/swift directory.
I called mine ‘PortableFoundation’, and when building as a dynamic library I was able to load it up like any other module.
···
On 18 May 2016, at 17:22, Karl Wagner <razielim@gmail.com> wrote: