digitalmars.D.announce - iOS LDC 0.16.1 (2.067.1) binaries available
- Dan Olson (27/27) Nov 04 2015 This is another set of binaries and universal libs for the experimental
- Dan Olson (6/13) Nov 05 2015 Just noticed that tvOS and watchOS are now present in LLVM, so I think
- Joakim (9/11) Nov 05 2015 Great, your last announcement was linked in reddit comments about
- Joakim (6/10) Nov 06 2015 btw, std.internal.math.gammafunction hasn't given me a problem
This is another set of binaries and universal libs for the experimental LDC iOS cross-compiler. It is now based on LDC 0.16.1 (2.067.1) and LLVM 3.6.2. https://github.com/smolt/ldc-iphone-dev/releases/tag/ios-0.16.1-151104 Feedback appreciated, especially since iOS support may get into official LDC sometime soon. This is a good time to voice an opinion on the approach. The release download ldc2-ios-0.16.1-151104-osx.tar.xz should have everything needed to run on an OS X build host in the same fashion as an LDC release. Binary is named iphoneos-ldc2 so you can have both it and a native ldc2 in your PATH. Usage of iphoneos-ldc2 is the same as ldc2 with the addition of clang style -arch option to select the iOS architecture to compile code for. Valid -arch options are armv6, armv7, armv7s, arm64, X86_64, or i386 (armv6 is not included in the druntime/phobos universal libs however). Xcode or similar is needed to link and bundle an iOS app. Xcode is not D aware and a working plugin is needed. In the meantime, xc-iphoneos-dc in the bin dir can be used as a custom *.d build script. Or you can compile D source externally and add your libraries/object files to an Xcode project. If you want to build LDC and the libs yourself, instructions are at: https://github.com/smolt/ldc-iphone-dev It is not a quick build because druntime and phobos have to be compiled for five architectures (armv7, armv7s, arm64, i386, and x86_64). -- Dan
Nov 04 2015
Just a few more notes: Dan Olson <gorox comcast.net> writes:Feedback appreciated, especially since iOS support may get into official LDC sometime soon. This is a good time to voice an opinion on the approach.Just noticed that tvOS and watchOS are now present in LLVM, so I think support for these could be added to LDC soon too.Xcode is not D aware and a working plugin is needed. In the meantime, xc-iphoneos-dc in the bin dir can be used as a custom *.d build script. Or you can compile D source externally and add your libraries/object files to an Xcode project.An Xcode plugin for D is badly needed. I think someone could get this one functioning: https://github.com/michelf/d-for-xcode
Nov 05 2015
Great, your last announcement was linked in reddit comments about the 2.069 release, when asked about iOS support. On Thursday, 5 November 2015 at 08:05:39 UTC, Dan Olson wrote:Just noticed that tvOS and watchOS are now present in LLVM, so I think support for these could be added to LDC soon too.WatchOS and tvOS are bitcode-only, right? Have they specified their bitcode format yet or is it just whatever clang spits out? I thought there were problems with that because of bitcode format changes over time and other platform issues, that the PNaCl guys had to work on solving. I wonder if you'll have similar issues with the bitcode ldc spits out.
Nov 05 2015
Joakim <dlang joakim.fea.st> writes:Great, your last announcement was linked in reddit comments about the 2.069 release, when asked about iOS support. On Thursday, 5 November 2015 at 08:05:39 UTC, Dan Olson wrote:tvOS is essentially iOS and doesn't require bitcode (yet) like watchOS. I am looking at adding it soon because Xcode 7 enables it by default. I don't totally appreciate all the possible bitcode problems, but one of the suggestions that apps can be updated for new CPUs without rebuilding doesn't make sense. The IR/bitcode from clang for arm64 and armv7 is different. They would have to make all the ABIs identical first or have LLVM backend do more of the ABI work. -- DanJust noticed that tvOS and watchOS are now present in LLVM, so I think support for these could be added to LDC soon too.WatchOS and tvOS are bitcode-only, right? Have they specified their bitcode format yet or is it just whatever clang spits out? I thought there were problems with that because of bitcode format changes over time and other platform issues, that the PNaCl guys had to work on solving. I wonder if you'll have similar issues with the bitcode ldc spits out.
Nov 05 2015
Joakim <dlang joakim.fea.st> On Thursday, 5 November 2015 at 15:45:35 UTC, Dan Olson wrote:tvOS is essentially iOS and doesn't require bitcode (yet) like watchOS. I am looking at adding it soon because Xcode 7 enables it by default.I just looked it up, their official docs say bitcode is required for both tvOS and watchOS: https://developer.apple.com/library/watchos/documentation/IDEs/Conceptual/AppDistributionGuide/AppThinning/AppThinning.htmlI don't totally appreciate all the possible bitcode problems, but one of the suggestions that apps can be updated for new CPUs without rebuilding doesn't make sense. The IR/bitcode from clang for arm64 and armv7 is different. They would have to make all the ABIs identical first or have LLVM backend do more of the ABI work.Yeah, that's what google did with PNaCl, stabilize on one format and make it as architecture-agnostic as possible: http://www.phoronix.com/scan.php?page=news_item&px=MTQyNTE Maybe Apple doesn't really care about running on different architectures, but I wonder what they're doing to handle changes in the llvm bitcode format over time.
Nov 05 2015
On Thursday, 5 November 2015 at 07:44:48 UTC, Dan Olson wrote:This is another set of binaries and universal libs for the experimental LDC iOS cross-compiler. It is now based on LDC 0.16.1 (2.067.1) and LLVM 3.6.2. https://github.com/smolt/ldc-iphone-dev/releases/tag/ios-0.16.1-151104btw, std.internal.math.gammafunction hasn't given me a problem since 2.067.1, the Win64 guys fixed it. 2.068 added a function that needs a CTFE-able 64-bit log2, but other than that, it just works now. You may want to revert your patch for that module and try it.
Nov 06 2015
Joakim <dlang joakim.fea.st> writes:btw, std.internal.math.gammafunction hasn't given me a problem since 2.067.1, the Win64 guys fixed it. 2.068 added a function that needs a CTFE-able 64-bit log2, but other than that, it just works now. You may want to revert your patch for that module and try it.Thanks for the tip, I'll check it out. It is the one remaining bad boy.
Nov 06 2015
Dan Olson <gorox comcast.net> writes:Joakim <dlang joakim.fea.st> writes:Still bad :-(btw, std.internal.math.gammafunction hasn't given me a problem since 2.067.1, the Win64 guys fixed it. 2.068 added a function that needs a CTFE-able 64-bit log2, but other than that, it just works now. You may want to revert your patch for that module and try it.Thanks for the tip, I'll check it out. It is the one remaining bad boy.
Nov 07 2015
On Saturday, 7 November 2015 at 19:20:02 UTC, Dan Olson wrote:Dan Olson <gorox comcast.net> writes:Hmm, that's strange, this commit didn't fix the 64-bit issues for you? I believe it fixed them for me on Android/ARM: https://github.com/ldc-developers/phobos/commit/9d1b49578ffa4b2e848159cfe5afe80b5e4c26ebJoakim <dlang joakim.fea.st> writes:Still bad :-(btw, std.internal.math.gammafunction hasn't given me a problem since 2.067.1, the Win64 guys fixed it. 2.068 added a function that needs a CTFE-able 64-bit log2, but other than that, it just works now. You may want to revert your patch for that module and try it.Thanks for the tip, I'll check it out. It is the one remaining bad boy.
Nov 07 2015
Joakim <dlang joakim.fea.st> writes:On Saturday, 7 November 2015 at 19:20:02 UTC, Dan Olson wrote:Yes, but there is still one case not working for both iOS armv7 and arm64 in 0.16.1. It is only off by one ulp so I'll make a PR for that. https://github.com/ldc-developers/phobos/blob/ldc/std/internal/math/gammafunction.d#L540 And then this new stuff in 2.068 is failing in various places. https://github.com/ldc-developers/phobos/commit/9b86eebed53c800a58dfa7e065dcb9e11cdae5c5Dan Olson <gorox comcast.net> writes:Hmm, that's strange, this commit didn't fix the 64-bit issues for you? I believe it fixed them for me on Android/ARM: https://github.com/ldc-developers/phobos/commit/9d1b49578ffa4b2e848159cfe5afe80b5e4c26ebJoakim <dlang joakim.fea.st> writes:Still bad :-(btw, std.internal.math.gammafunction hasn't given me a problem since 2.067.1, the Win64 guys fixed it. 2.068 added a function that needs a CTFE-able 64-bit log2, but other than that, it just works now. You may want to revert your patch for that module and try it.Thanks for the tip, I'll check it out. It is the one remaining bad boy.
Nov 07 2015
On Saturday, 7 November 2015 at 20:34:06 UTC, Dan Olson wrote:Joakim <dlang joakim.fea.st> writes:OK, somehow doesn't assert for me on Android/ARMv7.Hmm, that's strange, this commit didn't fix the 64-bit issues for you? I believe it fixed them for me on Android/ARM: https://github.com/ldc-developers/phobos/commit/9d1b49578ffa4b2e848159cfe5afe80b5e4c26ebYes, but there is still one case not working for both iOS armv7 and arm64 in 0.16.1. It is only off by one ulp so I'll make a PR for that. https://github.com/ldc-developers/phobos/blob/ldc/std/internal/math/gammafunction.d#L540And then this new stuff in 2.068 is failing in various places. https://github.com/ldc-developers/phobos/commit/9b86eebed53c800a58dfa7e065dcb9e11cdae5c5Yeah, that's the new function I mentioned earlier. Initializing the constant maxY ends up calling log2 through CTFE, the intrinsic for which doesn't exist in Kai's longdouble2 branch. I was going to look at writing one, feel free to beat me to it. ;) Or if you added that log2 to your branch already, could be other issues too, haven't gotten that far.
Nov 07 2015
Joakim <dlang joakim.fea.st> writes:On Saturday, 7 November 2015 at 20:34:06 UTC, Dan Olson wrote:Different math libs I suspect is the cause.Joakim <dlang joakim.fea.st> writes:OK, somehow doesn't assert for me on Android/ARMv7.Hmm, that's strange, this commit didn't fix the 64-bit issues for you? I believe it fixed them for me on Android/ARM: https://github.com/ldc-developers/phobos/commit/9d1b49578ffa4b2e848159cfe5afe80b5e4c26ebYes, but there is still one case not working for both iOS armv7 and arm64 in 0.16.1. It is only off by one ulp so I'll make a PR for that. https://github.com/ldc-developers/phobos/blob/ldc/std/internal/math/gammafunction.d#L540I don't use longdouble2 branch currently, but only because I had another simpler 64-bit specific solution. Yes, I had to add log() to it for CTFE. longdouble2 does need to get into LDC to make general support of cross-compilers easier. Kai's main concern was about CTFE accuracy for functions like sin(). Someone or us should start on that. I traced through the new gammafunction errors and several are due to subnormals getting fed to log(). Many iOS math functions treat subnormals as zero, producing different results. I just have to find them and revise the unitttests.And then this new stuff in 2.068 is failing in various places. https://github.com/ldc-developers/phobos/commit/9b86eebed53c800a58dfa7e065dcb9e11cdae5c5Yeah, that's the new function I mentioned earlier. Initializing the constant maxY ends up calling log2 through CTFE, the intrinsic for which doesn't exist in Kai's longdouble2 branch. I was going to look at writing one, feel free to beat me to it. ;) Or if you added that log2 to your branch already, could be other issues too, haven't gotten that far.
Nov 07 2015