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-us...@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 <phaus...@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? >>> >>> Thanks >>> >>> Karl >>> _______________________________________________ >>> swift-dev mailing list >>> swift-dev@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-dev > _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
