www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - D on android and d_android

reply burt <invalid_email_address cab.abc> writes:
Hi,

I'm trying to compile a simple app with D code to Android and 
trying to use the d_android library for this. While trying to 
compile a basic sample, I found a README [0] that mentions an 
"android-dub-build.d" script, which should be a wrapper around 
`dub build`, but I cannot find this file after downloading the 
dub package and also not on github; is this a mistake, or should 
I find it somewhere else?

Thank you in advance.

[0] 
https://github.com/adamdruppe/d_android/tree/master/android-dub-test
Apr 01 2020
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 1 April 2020 at 08:50:01 UTC, burt wrote:

 I found a README [0] that mentions an "android-dub-build.d" 
 script, which should be a wrapper around `dub build`


Ah, I forgot to update that file. There is no android-dub-build 
anymore, instead the android-setup changes the main configuration 
file so plain `dub build` just works.

So the correct steps now:

1) get ldc 1.19 specifically and the android NDK
2) do `android-setup /path/to/your/android/ndk`
3) do normal `dub build`
Apr 01 2020
parent reply burt <invalid_email_address cab.abc> writes:
On Wednesday, 1 April 2020 at 11:57:58 UTC, Adam D. Ruppe wrote:

 On Wednesday, 1 April 2020 at 08:50:01 UTC, burt wrote:

 I found a README [0] that mentions an "android-dub-build.d" 
 script, which should be a wrapper around `dub build`


 Ah, I forgot to update that file. There is no android-dub-build 
 anymore, instead the android-setup changes the main 
 configuration file so plain `dub build` just works.

 So the correct steps now:

 1) get ldc 1.19 specifically and the android NDK
 2) do `android-setup /path/to/your/android/ndk`
 3) do normal `dub build`


Thank you for your response, I managed to get a simple 
no-druntime-no-phobos app running with a function written in D.

Now I am trying to create a wrapper around a library that uses 
the runtime and phobos extensively, and even though the 
`libphobos2-ldc.a` and `libdruntime-ldc.a` files (created by 
`android-setup.d`) have been linked into the .a file that 
resulted from using

 dub build --compiler=ldc2 --arch=armv7a-none-linux-android


on my library, I still get linker errors telling me that symbols 
from phobos and druntime are undefined. (At least, I think I 
linked them in properly, because the size is approximately equal 
to the sizes of `libphobos2-ldc.a` and `libdruntime-ldc.a` added 
up.) Do you have any idea what could be wrong with my setup?

I am on windows and am using Android Studio v3.6.1, NDK 
21.0.6113669 and the newest version of LDC2.

Thanks in advance.
Apr 01 2020
parent reply burt <invalid_email_address cab.abc> writes:
 So the correct steps now:

 1) get ldc 1.19 specifically and the android NDK
 2) do `android-setup /path/to/your/android/ndk`
 3) do normal `dub build`




Sorry, I must have misread this. My LDC version was 1.20.1, not 
1.19.

Thanks
Apr 01 2020
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 1 April 2020 at 13:36:29 UTC, burt wrote:

 Sorry, I must have misread this. My LDC version was 1.20.1, not 
 1.19.


did that fix the linker error?

The runtimes it downloads are specifically built against 1.19. 
But libs for the other versions are available too, you just need 
to download the Android versions of ldc and copy them out to the 
appropriate place. My downloader just isn't smart enough to do 
it... yet. It is on my todo list though, just so are a million 
other things.
Apr 01 2020
parent reply burt <invalid_email_address cab.abc> writes:
On Wednesday, 1 April 2020 at 14:00:39 UTC, Adam D. Ruppe wrote:

 On Wednesday, 1 April 2020 at 13:36:29 UTC, burt wrote:

 Sorry, I must have misread this. My LDC version was 1.20.1, 
 not 1.19.


 did that fix the linker error?

 The runtimes it downloads are specifically built against 1.19. 
 But libs for the other versions are available too, you just 
 need to download the Android versions of ldc and copy them out 
 to the appropriate place. My downloader just isn't smart enough 
 to do it... yet. It is on my todo list though, just so are a 
 million other things.


Unfortunately downgrading my LDC to 1.19 did not fix the linker 
errors. I used `android-setup.d` for this version again and 
recompiled my project using LDC 1.19, however the errors still 
occur.

I also wonder if there's a difference between the libphobos2-ldc 
and libphobos2-ldc-debug.a libraries? Do those mangle differently 
and could that cause the linker errors?
Apr 01 2020
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 1 April 2020 at 14:13:32 UTC, burt wrote:

 I also wonder if there's a difference between the 
 libphobos2-ldc and libphobos2-ldc-debug.a libraries? Do those 
 mangle differently and could that cause the linker errors?


maybe. what are the errors?
Apr 01 2020
parent reply burt <invalid_email_address cab.abc> writes:
On Wednesday, 1 April 2020 at 14:16:28 UTC, Adam D. Ruppe wrote:

 On Wednesday, 1 April 2020 at 14:13:32 UTC, burt wrote:

 I also wonder if there's a difference between the 
 libphobos2-ldc and libphobos2-ldc-debug.a libraries? Do those 
 mangle differently and could that cause the linker errors?


 maybe. what are the errors?


Some examples of errors are:


 ...\ldc2-1.19.0-windows-x64\bin\..\import\std/utf.d:0: error: 
 undefined reference to '_D3std3utf12UTFException7__ClassZ'



 ...\dub\packages\arsd-official-7.0.0\arsd-official/jni.d:0: 
 error: undefined reference to '_D9Exception6__initZ'



 ...\ldc2-1.19.0-windows-x64\bin\..\import/object.d:3109: error: 
 undefined reference to '_d_arraysetcapacity'



 .../parser.d:697: error: undefined reference to '_d_newarrayU'


Strange is that even symbols that are not mangled (such as 
_d_arraysetcapacity) cannot be found, even though these should 
always mangle the same.
Apr 01 2020
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 1 April 2020 at 14:20:25 UTC, burt wrote:

 Some examples of errors are:


Those mean it isn't linking in the libs at all... ugh.

do

ldc2 -v

and it will tell you where the config file is.

open that up and see if it has teh correct paths under a section 
that looks kinda like

"armv7a-.*-linux-android":
{
     switches = [
         "-defaultlib=phobos2-ldc,druntime-ldc",
         "-link-defaultlib-shared=false",
         
"-gcc=$NDK/toolchains/llvm/prebuilt/$OS/bin/armv7a-linux-androideabi21-clang$EXT",
         "-linker=bfd",
         "-mcpu=cortex-a8",
     ];
     lib-dirs = [
         "$D_ANDROID/runtime_droid_armeabi-v7a",
     ];




That lib-dirs one in particular is what I'm interested in.
Apr 01 2020
parent reply burt <invalid_email_address cab.abc> writes:
On Wednesday, 1 April 2020 at 14:31:45 UTC, Adam D. Ruppe wrote:

 On Wednesday, 1 April 2020 at 14:20:25 UTC, burt wrote:

 Some examples of errors are:


 Those mean it isn't linking in the libs at all... ugh.

 do

 ldc2 -v

 and it will tell you where the config file is.

 open that up and see if it has teh correct paths under a 
 section that looks kinda like

 "armv7a-.*-linux-android":
 {
     switches = [
         "-defaultlib=phobos2-ldc,druntime-ldc",
         "-link-defaultlib-shared=false",
         
 "-gcc=$NDK/toolchains/llvm/prebuilt/$OS/bin/armv7a-linux-androideabi21-clang$EXT",
         "-linker=bfd",
         "-mcpu=cortex-a8",
     ];
     lib-dirs = [
         "$D_ANDROID/runtime_droid_armeabi-v7a",
     ];

 That lib-dirs one in particular is what I'm interested in.


It gives me lib-dirs = [ 
"C:/Users/<myname>/Programs/runtime_droid_armeabi-v7a", ];

At that location this folder is located and the contents are 
libdruntime-ldc.a, libdruntime-ldc-debug.a, libphobos2-ldc.a and 
libphobos2-ldc-debug.a. Sizes are 2511 kB, 4792 kB, 10.010 kB and 
17.378 kB respectively.

During another attempt I copied those folder to my dub project 
and included the path to those folders in my dub.json as 
"lflags": ["--library-path=./runtime_droid_armeabi-v7a"]. This 
gave me exactly the same errors.

Other ldc2.conf contents for that section was as follows:
switches = [
         "-defaultlib=phobos2-ldc,druntime-ldc",
         "-link-defaultlib-shared=false",
         
"-gcc=C:/Users/<user>/AppData/Local/Android/Sdk/ndk/21.0.6113669/toolchains/llvm/prebuilt/windows-x86_64/bin/armv7a-linux-androideabi21-clang.cmd",
         "-linker=bfd",
         "-mcpu=cortex-a8",
     ];
Apr 01 2020
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 1 April 2020 at 14:54:35 UTC, burt wrote:

 libphobos2-ldc.a and libphobos2-ldc-debug.a. Sizes are 2511 kB, 
 4792 kB, 10.010 kB and 17.378 kB respectively.


Those latter two should be megabytes not kilobytes.... the 
download must have failed.

can i come back to it in a few hours? I'll see about rewriting 
that thing and testing from scratch again.......
Apr 01 2020
parent reply burt <invalid_email_address cab.abc> writes:
On Wednesday, 1 April 2020 at 15:01:02 UTC, Adam D. Ruppe wrote:

 On Wednesday, 1 April 2020 at 14:54:35 UTC, burt wrote:

 libphobos2-ldc.a and libphobos2-ldc-debug.a. Sizes are 2511 
 kB, 4792 kB, 10.010 kB and 17.378 kB respectively.


 Those latter two should be megabytes not kilobytes.... the 
 download must have failed.


Well I'm European, so with 10.010 kB I mean 10010 kB = 10.010 MB 
in American/British.


 can i come back to it in a few hours? I'll see about rewriting 
 that thing and testing from scratch again.......


Well, I won't be able to finish it today anyway, so take your 
time.
Apr 01 2020
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 1 April 2020 at 15:04:02 UTC, burt wrote:

 Well I'm European, so with 10.010 kB I mean 10010 kB = 10.010 
 MB in American/British.


ah, of course.


 Well, I won't be able to finish it today anyway, so take your 
 time.


I rewrote the downloader so it goes straight from ldc releases 
instead of depending on me, so this should give a lot more 
compatibility. Also made `dub run d_android:setup` a thing 
(though dub sometimes will try to run what it already has and it 
needs the new version for this, so you might need to fetch new 
version first). And fixed a bit in readme and other bugs...

I only did rudimentary testing though... compiled my test on 
linux with no error so I think it is good. I'll be on my Windows 
computer tomorrow and be able to run more tests there.

But if you get to it before me, it *might* work now. You may have 
to edit your ldc2.conf file and delete the old generated addons 
to give it a cleaner slate too.

otherwise, I'll email again once I get a chance to test it more 
in the morning. (I'm in US Eastern so you are several hours ahead 
of me in Europe!)
Apr 01 2020
parent reply burt <invalid_email_address cab.abc> writes:
On Thursday, 2 April 2020 at 01:53:30 UTC, Adam D. Ruppe wrote:

 On Wednesday, 1 April 2020 at 15:04:02 UTC, burt wrote:

 Well I'm European, so with 10.010 kB I mean 10010 kB = 10.010 
 MB in American/British.


 ah, of course.


 Well, I won't be able to finish it today anyway, so take your 
 time.


 I rewrote the downloader so it goes straight from ldc releases 
 instead of depending on me, so this should give a lot more 
 compatibility. Also made `dub run d_android:setup` a thing 
 (though dub sometimes will try to run what it already has and 
 it needs the new version for this, so you might need to fetch 
 new version first). And fixed a bit in readme and other bugs...

 I only did rudimentary testing though... compiled my test on 
 linux with no error so I think it is good. I'll be on my 
 Windows computer tomorrow and be able to run more tests there.

 But if you get to it before me, it *might* work now. You may 
 have to edit your ldc2.conf file and delete the old generated 
 addons to give it a cleaner slate too.

 otherwise, I'll email again once I get a chance to test it more 
 in the morning. (I'm in US Eastern so you are several hours 
 ahead of me in Europe!)


I did some more testing and investigated druntime-ldc and 
phobos2-ldc. They contained the symbols that were undefined 
according to the error messages, so clearly they are not being 
linked at all, even though when using -v flag it reported passing 
-lphobos2-ldc and -ldruntime-ldc flags and 
-LC:/Users/<...>/armeabi-v7a to the linker, which is the path to 
the directory that contained `libdruntime-ldc.a` and 
`libphobos2-ldc.a`, so it should have found those and linked 
them...

Anyway, I don't think this fails to work because of an error in 
the d_android library. If you find anything else that may cause 
it, I am glad to know, but thank you for your help.
Apr 02 2020
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 2 April 2020 at 11:29:24 UTC, burt wrote:

 Anyway, I don't think this fails to work because of an error in 
 the d_android library. If you find anything else that may cause 
 it, I am glad to know, but thank you for your help.


Well, it is supposed to be a "just works" setup helper, so 
anything in it is a problem! There was an off-by-one bug in the 
downloader, maybe that missing byte made ldc ignore the corrupted 
library file.
Apr 02 2020
next sibling parent reply burt <invalid_email_address cab.abc> writes:
On Thursday, 2 April 2020 at 12:13:27 UTC, Adam D. Ruppe wrote:

 On Thursday, 2 April 2020 at 11:29:24 UTC, burt wrote:

 Anyway, I don't think this fails to work because of an error 
 in the d_android library. If you find anything else that may 
 cause it, I am glad to know, but thank you for your help.


 Well, it is supposed to be a "just works" setup helper, so 
 anything in it is a problem! There was an off-by-one bug in the 
 downloader, maybe that missing byte made ldc ignore the 
 corrupted library file.


I think I managed to get phobos2 and druntime to link. However, I 
still get linker errors saying that the following symbols are 
undefined: statvfs, fmodl, modfl, getdelim, _tlsend, __bss_end__, 
_tlsstart, __libc_current_sigrtmin, __libc_current_sigrtmax, 
strtold. I'm not sure what to do about that; did I forget to link 
something or are these symbols not in the Android runtime?
Apr 02 2020
parent reply burt <invalid_email_address cab.abc> writes:
On Thursday, 2 April 2020 at 17:16:56 UTC, burt wrote:

 On Thursday, 2 April 2020 at 12:13:27 UTC, Adam D. Ruppe wrote:

 On Thursday, 2 April 2020 at 11:29:24 UTC, burt wrote:

 Anyway, I don't think this fails to work because of an error 
 in the d_android library. If you find anything else that may 
 cause it, I am glad to know, but thank you for your help.


 Well, it is supposed to be a "just works" setup helper, so 
 anything in it is a problem! There was an off-by-one bug in 
 the downloader, maybe that missing byte made ldc ignore the 
 corrupted library file.


 I think I managed to get phobos2 and druntime to link. However, 
 I still get linker errors saying that the following symbols are 
 undefined: statvfs, fmodl, modfl, getdelim, _tlsend, 
 __bss_end__, _tlsstart, __libc_current_sigrtmin, 
 __libc_current_sigrtmax, strtold. I'm not sure what to do about 
 that; did I forget to link something or are these symbols not 
 in the Android runtime?


I managed to narrow it down to just one error. The missing 
`_tlsstart` and `_tlsend` symbols were because of the missing 
`void main() {}`, that used to be added automatically in 
d_android v0.0.5 but not in v0.1.0. It worked when I added an 
empty main function.

Most of the other errors were because of the API level of 
Android; for whatever reason, Android Studio chose API level 16 
instead of at least 21, so changing minSdkVersion to 21 in 
build.gradle made those errors go away.

However, I still get one undefined reference to __bss_end__, and 
I don't know how to fix this. Is this also a problem with TLS or 
the API level?

Thanks.
Apr 05 2020
parent reply Jan =?UTF-8?B?SMO2bmln?= <hrominium gmail.com> writes:
Little off-topic, but I think it should fit here well.

Is there some "Hello World!" example for D on Android?
Having a simple example is a great springboard to start a project 
with lot of unknowns.

On the weekend I started creating an App (kotlin), really simple 
stuff.
However there is just so much to know.
It is really overwhelming.
Apr 06 2020
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 6 April 2020 at 08:38:03 UTC, Jan Hönig wrote:

 Is there some "Hello World!" example for D on Android?


So I did a tiny thing in the repo:

https://github.com/adamdruppe/d_android/tree/master/android-dub-test

if you open that in android studio it should load up, and the 
makefile is commented, but tells you the 8 commands (4 dub 
builds, 4 file copies, just doing the same things for each of the 
4 android architecture targets) to do a full add.

The main program is still in Java - there's a way to do pure D, 
the NDK's NativeActivity, but I never tried it personally (tbh 
I've only actually done hello world in android at all, i have 
zero interest in mobile dev, i just did it cuz someone had to do 
something and the JNI meta code was kinda cool) - but then you 
can call to/from D/java with native methods.



 However there is just so much to know.
 It is really overwhelming.


no kidding, I spent several weekends just trying to understand 
the setup and build process. And I still basically don't really 
know, which is why my thing there builds the D code externally 
and copies the files where gradle can find them instead of 
actually changing the gradle config.
Apr 07 2020
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Apr 07, 2020 at 12:43:20PM +0000, Adam D. Ruppe via Digitalmars-d-learn
wrote:

 next sibling parent  Jan =?UTF-8?B?SMO2bmln?= <hrominium gmail.com>  writes:


On Tuesday, 7 April 2020 at 14:51:15 UTC, H. S. Teoh wrote:

 On Tue, Apr 07, 2020 at 12:43:20PM +0000, Adam D. Ruppe via 
 Digitalmars-d-learn wrote:

 On Monday, 6 April 2020 at 08:38:03 UTC, Jan Hönig wrote:

 Is there some "Hello World!" example for D on Android?




 [...]

 However there is just so much to know.
 It is really overwhelming.


 
 no kidding, I spent several weekends just trying to understand 
 the setup and build process. And I still basically don't 
 really know, which is why my thing there builds the D code 
 externally and copies the files where gradle can find them 
 instead of actually changing the gradle config.


 I managed to build APKs without Gradle (yes, I'm crazy like 
 that). There are several steps, and you do need some tools from 
 the Android SDK/NDK, namely aapt, apksigner, dx (called 
 dalvik-exchange on some distros), zipalign, and a Java 1.7 
 compiler (the last time I checked; maybe they support 1.8 now, 
 I don't know).

 I haven't tried a native app so far, so the way I set it up is 
 to create a dummy Java wrapper that contains main() that calls 
 native methods that are implemented in D.  You can use Adam's 
 jni.d to generate implementations for your native methods.

 Steps:

 1) Follow LDC wiki to build an Android cross-compiler and 
 cross-compiled
    LDC libraries (this may already be prepackaged with the 
 latest LDC
    releases). Most important thing you need is the path to the 
 droid32
    or droid64 directories containing the libraries 
 libdruntime-ldc.a,
    libphobos2-ldc.a, libdruntime-ldc-debug.a, 
 libphobos2-ldc-debug.a.



 2) Generate R.java:


 	/usr/bin/aapt package -f -m -M AndroidManifest.xml -S res -I 
 ${PATH_TO_ANDROID_SDK}/platforms/android-${TARGET_API_LEVEL}/android.jar -J
${PATH_TO_JAVA_SOURCE_CODE}

 3) Compile Java sources:

 	/usr/bin/javac -source 1.7 -target 1.7 -bootclasspath 
 ${PATH_TO_ANDROID_SDK}/platforms/android-${TARGET_API_LEVEL}/android.jar -d
obj -sourcepath src ${JAVA_SOURCE_FILES (including R.java)}

 4) Generate classes.dex (on some systems dalvik-exchange might 
 be called
 simply 'dx'):

 	/usr/bin/dalvik-exchange --dex --output=classes.dex 
 ${PATH_TO_OBJ_DIR}

 5) Setup linker config file (for optimizing apk size):

 	LINKER_VERSION_FILE=lib${YOUR_APP_NAME}.version
 	cat > $LINKER_VERSION_FILE
 	LIBGAME_1.0 {
 		global:
 			Java_*;
 		local:
 			*;
 	};

 6) Cross-compile D code with LDC:

 	${PATH_TO_LDC}/bin/ldmd2 -c 
 -mtriple=armv7-none-linux-androideabi -mcpu=cortex-a8 
 -L-L${DROID32_PATH}/lib -Xcc=-fpie -Xcc=-pie 
 -Xcc=--sysroot=${PATH_TO_ANDROID_NDK}/platforms/android-${TARGET
API_LEVEL}/arch-arm -Xcc=-fuse-ld=bfd -Xcc=-gcc-toolchain
-Xcc=${PATH_TO_ANDROID_NDK}/toolchains/arm-linux-androideabi-4.9/p
ebuilt/linux-x86_64 -Xcc=-target -Xcc=armv7-none-linux-androideabi -O4 -inline
-Isrc/d -od${PATH_TO_OBJ_DIR} ${D_SOURCE_FILES}
 	${PATH_TO_ANDROID_NDK}/toolchains/llvm/prebuilt/linux-x86_64/bin/clang
-Wl,-soname,lib${YOUR_APP_NAME}.so -shared -Wl,--gc-sections
-Wl,--version-script=${LINKER_VERSION_FILE} -llog -landroid -lEGL -lGLESv2
--sysroot=${PATH_TO_ANDROID_NDK}/platforms/android-${TARGET_API_LEVEL}/arch-arm
-fuse-ld=bfd -gcc-toolchain
${PATH_TO_ANDROID_NDK}/toolchains/arm-linux-androideabi-4.9/p
ebuilt/linux-x86_64 -target armv7-none-linux-androideabi ${D_OBJECT_FILES}
${DROID32_PATH}/lib/libphobos2-ldc.a ${DROID32_PATH}/lib/libdruntime-ldc.a -o
lib/armeabi-v7a/lib${YOUR_APP_NAME}.so

 7) Create unaligned APK:
 	/usr/bin/aapt package -f -m -M AndroidManifest.xml -S res -I 
 ${PATH_TO_ANDROID_SDK}/platforms/android-${TARGET_API_LEVEL}/android.jar -F
bin/${YOUR_APP_NAME}.unaligned.apk
 	/usr/bin/aapt add bin/${YOUR_APP_NAME}.unaligned.apk 
 classes.dex
 	/usr/bin/aapt add bin/${YOUR_APP_NAME}.unaligned.apk 
 lib/armeabi-v7a/lib${YOUR_APP_NAME}.so

 8) Sign the APK:
 	/usr/bin/apksigner sign --ks-pass 
 file:${YOUR_SIGNING_KEY_PASSWORD_FILE} --ks 
 ${YOUR_SIGNING_KEY_STORE_FILE} 
 bin/${YOUR_APP_NAME}.unaligned.apk

 9) Align the APK:
 	/usr/bin/zipalign -f 4 bin/${YOUR_APP_NAME}.unaligned.apk 
 bin/${YOUR_APP_NAME}.apk

 10) Copy bin/${YOUR_APP_NAME}.apk to your device and install it.


 T


Thanks for the effort. I will try the "easy" way frist :D



 Apr 07 2020



prev sibling  parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


On Tuesday, 7 April 2020 at 14:51:15 UTC, H. S. Teoh wrote:

 1) Follow LDC wiki to build an Android cross-compiler and 
 cross-compiled
    LDC libraries (this may already be prepackaged with the 
 latest LDC
    releases).



They are - this is all automatic just-works now (if you download 
the right versions - my android-setup.d will grab the appropriate 
binaries from ldc repo for you).



 6) Cross-compile D code with LDC:


And my android-setup.d also changes the ldc config file to 
automate most this - you just set the mtriple (and optionally, 
mcpu) and the rest is automatic too.



I've had more bugs than time so the full-on "just works" promise 
is "your mileage may vary" but it is really getting simplified 
for these two steps.



 Apr 07 2020



  parent  "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Tue, Apr 07, 2020 at 03:06:16PM +0000, Adam D. Ruppe via Digitalmars-d-learn
wrote:

 On Tuesday, 7 April 2020 at 14:51:15 UTC, H. S. Teoh wrote:

 1) Follow LDC wiki to build an Android cross-compiler and
    cross-compiled LDC libraries (this may already be prepackaged
    with the latest LDC releases).


 
 They are - this is all automatic just-works now (if you download the
 right versions - my android-setup.d will grab the appropriate binaries
 from ldc repo for you).


Nice!  I'm totally loving how the LDC maintainers have been packaging
everything in such a convenient, easy-to-use way.  I've been doing
cross-compilation to Windows, and it's been great, I don't even need a
Windows machine, just cross-compile to Windows with the right triple and
library paths set in ldc2.conf, and it Just Works(tm).



 6) Cross-compile D code with LDC:


 
 And my android-setup.d also changes the ldc config file to automate
 most this - you just set the mtriple (and optionally, mcpu) and the
 rest is automatic too.


Very nice!


[...]

 I've had more bugs than time so the full-on "just works" promise is
 "your mileage may vary" but it is really getting simplified for these
 two steps.


The rest are Android-specific, but in theory easily scriptable (in fact,
I typed it up by copy-n-pasting from the output of my SCons build script
:P).  So in theory, one *could* write a script that does it all in one
go.


T

-- 
People say I'm arrogant, and I'm proud of it.



 Apr 07 2020



prev sibling  parent  Jan =?UTF-8?B?SMO2bmln?= <hrominium gmail.com>  writes:


On Tuesday, 7 April 2020 at 12:43:20 UTC, Adam D. Ruppe wrote:

 On Monday, 6 April 2020 at 08:38:03 UTC, Jan Hönig wrote:

 Is there some "Hello World!" example for D on Android?


 So I did a tiny thing in the repo:

 https://github.com/adamdruppe/d_android/tree/master/android-dub-test

 if you open that in android studio it should load up, and the 
 makefile is commented, but tells you the 8 commands (4 dub 
 builds, 4 file copies, just doing the same things for each of 
 the 4 android architecture targets) to do a full add.



Thanks a lot. I was blind not finding it in your repo.



 Apr 07 2020



prev sibling  parent reply burt <invalid_email_address cab.abc>  writes:


On Thursday, 2 April 2020 at 12:13:27 UTC, Adam D. Ruppe wrote:

 On Thursday, 2 April 2020 at 11:29:24 UTC, burt wrote:

 Anyway, I don't think this fails to work because of an error 
 in the d_android library. If you find anything else that may 
 cause it, I am glad to know, but thank you for your help.


 Well, it is supposed to be a "just works" setup helper, so 
 anything in it is a problem! There was an off-by-one bug in the 
 downloader, maybe that missing byte made ldc ignore the 
 corrupted library file.


I managed to get it to compile. I had to add __bss_end__ symbol 
myself and set the value to the value of the `_end` symbol or it 
wouldn't work. A PR to the LDC druntime is wat caused the 
__bss_end__ symbol to be missing [0]. However, when I added a 
MainActivity class in D using arsd.jni, the app crashes whenever 
one of the  Exported methods is called. My code looked like this:

```
import arsd.jni;

final class TextView : IJavaObject
{
     mixin IJavaObjectImplementation!(false);
     mixin JavaPackageId!("android.widget", "TextView");
}
mixin ImportExportImpl!TextView;

final class MainActivity : IJavaObject
{
      Export void dFunction(TextView input, TextView output, 
TextView historyItem)
     {
         // ...
     }

     mixin IJavaObjectImplementation!(false);
     mixin JavaPackageId!("com.mypackage.myapplication", 
"MainActivity");
}
mixin ImportExportImpl!MainActivity;
```

And a callback method for a button in Java called dFunction with 
the appropriate parameters. I noticed that the generated .so file 
didn't contain a 
`Java_com_mypackage_myapplication_MainActivity_dFunction` symbol. 
Any help on this would be appreciated.

Thanks.

[0] https://github.com/ldc-developers/druntime/pull/178



 Apr 07 2020



  parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


On Tuesday, 7 April 2020 at 11:45:24 UTC, burt wrote:

 I managed to get it to compile. I had to add __bss_end__ symbol 
 myself and set the value to the value of the `_end` symbol or 
 it wouldn't work. A PR to the LDC druntime is wat caused the 
 __bss_end__ symbol to be missing [0].


Blargh it was supposed to just work without main() on the new ldc 
but I only actually ran stuff with 1.19 on actual android.



 However, when I added a MainActivity class in D using arsd.jni, 
 the app crashes whenever one of the  Exported methods is called.


What does the android studio debugger say about it? Missing 
method or another link problem?


 And a callback method for a button in Java called dFunction 
 with the appropriate parameters. I noticed that the generated 
 .so file didn't contain a 
 `Java_com_mypackage_myapplication_MainActivity_dFunction` 
 symbol. Any help on this would be appreciated.


Yeah, it uses a private name and registers that in a static 
module constructor (this allows it to support overloads more 
easily), so that specific name not being there isn't wrong, but 
it could be the registration function never got called again.


sorry I've been so unresponsive on all this, I've had a lot other 
surprise/emergency stuff going on irl so I'm barely keeping up 
with my email.



 Apr 07 2020



  parent  burt <invalid_email_address cab.abc>  writes:


On Tuesday, 7 April 2020 at 12:29:57 UTC, Adam D. Ruppe wrote:

 On Tuesday, 7 April 2020 at 11:45:24 UTC, burt wrote:

 I managed to get it to compile. I had to add __bss_end__ 
 symbol myself and set the value to the value of the `_end` 
 symbol or it wouldn't work. A PR to the LDC druntime is wat 
 caused the __bss_end__ symbol to be missing [0].


 Blargh it was supposed to just work without main() on the new 
 ldc but I only actually ran stuff with 1.19 on actual android.



 However, when I added a MainActivity class in D using 
 arsd.jni, the app crashes whenever one of the  Exported 
 methods is called.


 What does the android studio debugger say about it? Missing 
 method or another link problem?


 And a callback method for a button in Java called dFunction 
 with the appropriate parameters. I noticed that the generated 
 .so file didn't contain a 
 `Java_com_mypackage_myapplication_MainActivity_dFunction` 
 symbol. Any help on this would be appreciated.


 Yeah, it uses a private name and registers that in a static 
 module constructor (this allows it to support overloads more 
 easily), so that specific name not being there isn't wrong, but 
 it could be the registration function never got called again.


Error is as follows according to the logs:

java.lang.IllegalStateException: Could not execute method for 
android:onClick
         at [etc.]
Caused by: java.lang.reflect.InvocationTargetException
         at [etc.]
Caused by: java.lang.UnsatisfiedLinkError: No implementation 
found for void 
com.mypackage.myapplication.MainActivity.dFunction(android.widget.TextView,
android.widget.TextView, android.widget.TextView) (tried
Java_com_mypackage_myapplication_MainActivity_dFunction and
Java_com_mypackage_myapplication_MainActivity_dFunction__Landroid_widget_TextView_2Landroid_widget_TextView_2Landroid_widget_TextView_2)
         at [etc.]

So yes, it cannot find the function. How can I check if the 
module constructor is actually run?



 Apr 07 2020