FYI: Master is now at D 2.074.1

Joakim via digitalmars-d-ldc digitalmars-d-ldc at
Fri Jul 28 14:16:18 PDT 2017

On Friday, 28 July 2017 at 18:21:39 UTC, kinke wrote:
> Wrt. the LLVM patch: We'll most likely use LLVM 4.0.1 for 1.4 
> (finally on Windows too). If the patch is still required for 
> 4.0.1, we'll probably need to integrate it in our ldc-scripts 
> [1], so that we can update the Docker image once with that 
> tailored LLVM. Integrating the patch for LDC on Windows is 
> probably not worth the effort.

Why not?  It's small and only affects ELF TLS.  It would be nice 
for the Windows release of ldc to also work as an Android 
cross-compiler, to be used with the Android NDK for Windows.

> The runtime CMake script patch looks quite straightforward. The 
> CMake variables are best put into a dedicated 
> `` or something like it, which also 
> sets `TARGET_SYSTEM=Android;Linux;UNIX` so that Android can be 
> detected this way for the few special cases [is removing 
> core.stdc.tgmath really required?].

I was thinking they'd simply be told to add those flags to their 
command-line, but a standalone script would be even easier, sure. 
core.stdc.tgmath unfortunately doesn't compile right now, as I 
never bothered to figure out all the aliases for the missing 
Bionic math functions in core.stdc.math.

> So there should be no need to compile an additional combined 
> druntime+Phobos testrunner anymore; cross-compiling with the 
> script will yield the 2 normal separate testrunners (when 
> setting the env variable `MAKE_ARGS="all all-test-runners"`). 
> Afaict you didn't change anything there except for adding 
> `-d-debug`.

Yes, I'm looking forward to removing that and just using the 
existing command-line test-runners, properly cross-compiled.

> I don't know what libnative-activity*.so, the biggest part of 
> the patch, is; is it required?

No, I was planning on leaving that out and maybe trying to get it 
in later.  It takes a simple, fully native, OpenGLES 1.0 GUI 
Android app that I ported from the NDK examples and invokes the 
test runner from there, so you can build a test runner apk (apk 
is the file extension for full Android apps, what you see in the 
official app store):

It is good to test because the apk environment is slightly 
different from the command-line test-runner environment, because 
a native apk is a shared library that's invoked by their Java 
runtime.  I'm not sure if we want to test that as part of ldc 
too, but it can wait for later, even if we did.

More information about the digitalmars-d-ldc mailing list