FYI: Master is now at D 2.074.1
Joakim via digitalmars-d-ldc
digitalmars-d-ldc at puremagic.com
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
> , 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
> `build-ldc-runtime-android.sh` 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
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