On Friday, 10 July 2015 at 20:38:16 UTC, Rishub Nagpal wrote:
On Thursday, 9 July 2015 at 06:32:28 UTC, Dan Olson wrote:
I've made a set of binaries and universal libs for the LDC iOS cross-compiler. It is based on LDC 0.15.1 (2.066) and LLVM 3.5.1.


Only 32-bit devices currently; arm64 work starts next month when I acquire an iPhone 6.

The download should have everything needed to run on an OS X build host in the same fashion as LDC downloads. But I may have missed something. Feedback appreciated.

Good Work! I'd like to help get D to work on android, but I do not know much about llvm and arm compilers to be of much help. Last I heard there was an issue with exception handling and TLS, is that still so?

That's funny, because I was just thinking about putting my Android patches for ldc online and trying to get more people to chip in on working through the remaining tests to be fixed for Android/ARM.

I got TLS working a month and a half ago (http://forum.dlang.org/post/imkgasjuvbbasyghd...@forum.dlang.org) and exception-handling seems to be working since this fix I ferreted out last week (http://forum.dlang.org/post/qsfaussopqwwjuljd...@forum.dlang.org). Now it's just codegen issues, with about half of phobos modules' tests failing somewhere, though many of those modules only have a handful of tests that fail. For example, only three unit test blocks fail in std.stdio and one in std.path. Common causes appear to be problems with ranges and functions from std.random.

I'm going through each module and commenting out failing tests and checking backtraces, a time-consuming process that's got me thinking about hacking the test runner, so that failing tests in one unit test block won't stop other test blocks from the same module from running, as is the case now.

If you or anybody else is interested in chipping in, reply in the Android thread (first link above) and I'll put some patches and build info online. Unfortunately, to really fix any of these issues, you'll probably have to know something about ARM assembly, LLVM IR, and be comfortable stepping through the binary with gdb but without debug info, although simply triaging the tests to figure out what works and what doesn't could probably be done by almost anyone.

Reply via email to