On Monday, 9 January 2017 at 18:38:01 UTC, Ignacious wrote:
On Monday, 9 January 2017 at 08:28:04 UTC, Joakim wrote:
I've tried to write up detailed instructions on the wiki. I'm
still improving those and plan to spin off those two sections
I linked you, on how to just build the samples, into their own
page. You can contribute any steps you had to take with
Bash/Ubuntu on Windows with the prebuilt linux/x64
cross-compiler there, once I put the page up.
Yeah, I found it a bit confusing though. It seems like it is
written up by someone that is working on the core rather than a
newb! ;)
Yep, that's what it is. That's one reason why I want to add
another wiki page which will just focus on building the sample
apps, as opposed to building the cross-compiler too.
The main problem I have had seems to be that UoW uses ver 14.
Somehow I was able to upgrade by following docs online(wasn't
easy but eventually got there and everything seems to work...
I should have documented ;) but I wasn't sure if the process
would work. Supposedly ver 16 exists by one has to be part of
the dev team or something.
If you know all the steps to upgrade Ubuntu on Windows, you
may want to document them on the wiki page I will put up or
link to a good resource that shows how to do it.
I don't because it was all new to me(I didn't know there was
even such a thing as UoW. I simply searched for the errors I
got and tried different solutions until it worked. Luckily the
outcome worked... which is not always the case.
Is it easy for you to nuke it and go back to the original 14.04
setup? I may be able to remove some of those ldc library
dependencies, so that it works on the original setup too.
I think that it would be a boon for D to have some type of well
defined and well planned Android development suite rather than
what seems to be hacked/cobbled together. This would bring not
only more developers to D for android but also to D in general.
Yes, definitely the plan. The big problem right now is that it
requires a slightly modified llvm. If that weren't needed, we
could just have the official release builders also build the
standard library for Android/ARM on their OS.
I'm gonna try the opengl examples and hopefully the work. The
main problem I see is how to actually write "commercial" apps
using D for android. Can it be done successfully? Nobody knows
because there isn't a history. What are the exact steps, say,
to add ads, or interface with the subsystem? I saw that there
is some way to call some java stuff from D but seems like
nothing is thoroughly tested(most of the work as been just
trying to get things up and running).
I got interfacing with Java working late last year, through JNI.
Not "thoroughly tested" by any means, but seems to work. The
only way to know whether commercial Android apps can be written
in D is to actually do it. I plan on writing one this year.
On Monday, 9 January 2017 at 23:24:08 UTC, Ignacious wrote:
How difficult is it to build for x86/x64?
Would be nice to be able to use something like
http://www.android-x86.org/
as a test instead of an actual device.
Does one simply have to use the proper ldc2/dmd and link in the
correct libs? or is it more complex?
Not too hard. I haven't bothered with it because Android/x86 had
almost no market share, and Intel has essentially given up and
pulled out of that market. I may someday update it again, but
the problem right now is that I don't have an x86 machine on
which to try it. I've gone all ARM and setting Android/x86 up on
a VPS takes some work.
Also, I'm a bit confused on how to compile the source
examples(working it out and trying to explain the solutions as
I type)
https://wiki.dlang.org/Build_DMD_for_Android
As noted there, those instructions haven't been updated in a year
and a half and are out of date. I just updated the wiki page
with a stronger warning.
(set $NDK permanently)
I have done(easy, find the file and modify)
rt_init();
android_main(android_app);
rt_term();
Clean up and compile as before:
$NDK/ndk-build clean
NDK_TOOLCHAIN_VERSION=clang $NDK/ndk-build V=1
But no error. Object files for various architectures are
created though, it seems. (rt_ errors do no exist contrary to
what is said in the docs)
I'm not sure why that wouldn't error anymore, it should be the
same. Anyway, since I wrote those instructions a couple years
ago, I translated the google-provided android_native_app_glue.c
to android_native_app_glue.d and didn't bother updating the
instructions for Android/x86.
But the following seems need updating/explaining. I am using
prebuilt ldc2 for android from some link you provided. -android
doesn't seem to work and I can't find sensor.d (not sure if it
is needed anymore)?
../../../dmd/src/dmd -android -I../..
-ofobj/local/x86/objs/native-activity main.o -c jni/main.d
../../android/sensor.d
I had to change to use ldc2, remove -android, and obviously
change the file names and such(and download the android dir
from github).
$NDK/toolchains/llvm-3.5/prebuilt/linux-x86/bin/clang
-Wl,-soname,libnative-activity.so -shared
--sysroot=$NDK/platforms/android-9/arch-x86
./obj/local/x86/objs/native-activity/main.o
./obj/local/x86/libandroid_native_app_glue.a -lgcc
-gcc-toolchain $NDK/toolchains/x86-4.8/prebuilt/linux-x86
-target i686-none-linux-android -no-canonical-prefixes
-Wl,--no-undefined -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now
-L$NDK/platforms/android-9/arch-x86/usr/lib -llog -landroid
-lEGL -lGLESv1_CM -llog -lc -lm -fuse-ld=bfd
-L../../../phobos/generated/linux/release/32 -l:libphobos2.a -o
./libs/x86/libnative-activity.so
Seems a lot of the paths are wrong/different than what I have
$NDK/toolchains/llvm-3.5/prebuilt/linux-x86/bin/clang
-Wl,-soname,libhello-jni.so -shared
--sysroot=$NDK/platforms/android-9/arch-x86
./obj/local/x86/objs-debug/hello-jni/main.o
./obj/local/x86/libandroid_native_app_glue.a -lgcc
-gcc-toolchain $NDK/toolchains/x86-4.8/prebuilt/linux-x86
-target i686-none-linux-android -no-canonical-prefixes
-Wl,--no-undefined -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now
-L$NDK/platforms/android-9/arch-x86/usr/lib -llog -landroid
-lEGL -lGLESv1_CM -llog -lc -lm -fuse-ld=bfd
-L../../../phobos/generated/linux/release/32 -l:libphobos2.a -o
./libs/x86/libhello-jni.so
I am going to zip of what I have so you can see how the paths
are laid out: http://www.filedropper.com/ldc2android
There seems to be no obj file generated except for debug, that
was probably intentional but the given command line doesn't
represent that if so.
It is a bit confusing for the beginner to come along and try to
get all this to work when there is contradictory information.
Yes, that wiki page notes that it is out of date, which accounts
for most of the issues you noted.
The reason being is simple in that a beginner won't know what
is used for what and the docs essentially are give as "plug and
play" yet don't actually work... rather than being descriptive
and explaining exactly what is what(some of it should be
obvious but not all will be to someone that isn't versed in
linux and android development or used to windows which
abstracts everything).
What would be nice, at a minim, is a bash script that allows
one to adjust different variables for different situations and
then it can be used to compile. (e.g., set the obj path, ndk
path, ldc2 path, etc)
What really needs to be done, IMO, is to have a simple set of
tools(scripts or whatever) that can be configured easily and
abstracts the complexity. (I've done that for the test script I
made
#!/bin/bash
/mnt/c/dlang/ldc2Android/bin/ldc2 -c $1.d
$NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/clang
-Wl,-z,nocopyreloc --sysroot=$NDK/platforms/android-9/arch-arm
-lgcc -gcc-toolchain
$NDK/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64
-target armv7-none-linux-androideabi -no-canonical-prefixes
-fuse-ld=bfd -Wl,--fix-cortex-a8 -Wl,--no-undefined
-Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -fPIE -pie -mthumb
-Wl,--export-dynamic -lc -lm $1.o lib/libphobos2-ldc.a
lib/libdruntime-ldc.a -o $1
which does the compiling for me without having to type all that
junk in each time.. pretty simple but does the job, a more
advanced concept could be used to help make it easier on people
)
As I noted elsewhere, I am writing reggae files to automate
building the sample apps. The problem right now is that I have
to rewrite my reggae files to work with an external linker from
the NDK, as opposed to the native linker on my Android/ARM tablet:
https://github.com/atilaneves/reggae/issues/22
Once that's done, I will commit them to my Android repo so that
anyone can use them with reggae. The new wiki page will have
instructions on how to use it all together, while keeping the old
manual instructions around so you can see what they're actually
doing.
If you want, and you can accomplish this, if there was an
ldc2/dmd2 for android that runs on windows I could work on
getting it working for windows(as I prefer it rather than
linux, which I have no real experience with). I'm thinking
everything more or less would work similarly(since sdk/ndk
exists for windows). It would just be a matter of translating
paths and such. I could easily write a wrapper to reduce the
complexity.
I have not used Windows in more than a year. We used to have two
Windows devices at home 3-4 years ago, a laptop and an ultrabook,
now we have none. I suppose I could try setting up wine in a
VPS, but I'm not sure if that'd work and don't feel inclined to
try it. As I said earlier, when this cross-compiler can use
stock llvm, there will be official cross-compilers for every OS.
The main problem I seem to be having are path issues(e.g,
$NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/clang
rather than
$NDK/toolchains/llvm-3.5/prebuilt/linux-x86/bin/clang
,etc)
The final error I get is
clang: error: no such file or directory:
'./obj/local/x86/libandroid_native_app_glue.a'
and I can't find this file anywhere.
I assume I was suppose to get this file when I did
$NDK/ndk-build clean
NDK_TOOLCHAIN_VERSION=clang $NDK/ndk-build V=1
You should see the following linker error, as the linker can't
find the rt_init and rt_term functions you just added:
/home/joakim/android-ndk-r10/sources/android/native_app_glue/android_native_app_glue.c:232:
error: undefined reference to 'rt_init'
/home/joakim/android-ndk-r10/sources/android/native_app_glue/android_native_app_glue.c:234:
error: undefined reference to 'rt_term'
clang++: error: linker command failed with exit code 1 (use -v
to see invocation)
make: *** [obj/local/x86/libnative-activity.so] Error 1
but I didn't.
If I execute that command in the android_native_app_glue.c dir
I get
/opt/android-ndk-r13b/sources/android/native_app_glue#
NDK_TOOLCHAIN_VERSION=clang $NDK/ndk-build V=1
Android NDK: Could not find application project directory !
Android NDK: Please define the NDK_PROJECT_PATH variable to
point to it.
/opt/android-ndk-r13b/build/core/build-local.mk:151: ***
Android NDK: Aborting . Stop.
Of course, if I execute it in the project path I get a lot of
stuff but not that file anywhere.
I have dried to put
android_native_app_glue.d
in different places but nothing...
Once that is fixed I assume everything should work... but I'm
at a loss for what to do next. Any ideas?
If you really want to get it to work, you should replace the old
instructions for the app_glue C file with the ones for the D file
from the newer ldc/ARM wiki page. Still no guarantee that it'll
all work, as those instructions are written for dmd, while you
are using ldc, which hasn't been tried with Android/x86 in a
while.
Rather than use Android/x86 (which you are only doing because you
think it's easier to test Android apps on Android/x86 in a VM?),
I suggest you install the SDK, which comes with an Android/ARM
emulator, or run on an actual Android/ARM device, which is what I
do. You can hook a phone or tablet up through USB to your
Windows machine and control it better through adb.