www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Android Status

reply Ignacious <I.D.T ProjectMaya.com> writes:
What is the current status for building android apps in D? I 
would like to create simple graphic based apps but don't wanna 
get bogged down in trying to get car moving without any wheels.
Dec 28 2016
next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 28 December 2016 at 23:33:57 UTC, Ignacious wrote:

 What is the current status for building android apps in D? I 
 would like to create simple graphic based apps but don't wanna 
 get bogged down in trying to get car moving without any wheels.


https://forum.dlang.org/thread/ovkhtsdzlfzqrqneolyv forum.dlang.org?page=2
Dec 29 2016
prev sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Wednesday, 28 December 2016 at 23:33:57 UTC, Ignacious wrote:

 What is the current status for building android apps in D? I 
 would like to create simple graphic based apps but don't wanna 
 get bogged down in trying to get car moving without any wheels.


Should all work, but nothing other than small apps have been 
tested.  Try the latest beta, which I just put up:

http://forum.dlang.org/post/xetfqojxijgobisfacvx forum.dlang.org

If you want something more substantive than my ports of the NDK's 
sample apps, check out Vadim's Tetris app, which I spent half an 
hour playing on my phone, :) or his minecraft-like demo (click on 
the sourceforge link from his forum post to get the apps):

http://forum.dlang.org/thread/cdekkumjynhqoxvmgjze forum.dlang.org

Let me know if you have any questions or problems.
Dec 29 2016
next sibling parent Ignacious <I.D.T ProjectMaya.com> writes:
On Thursday, 29 December 2016 at 10:14:53 UTC, Joakim wrote:

 On Wednesday, 28 December 2016 at 23:33:57 UTC, Ignacious wrote:

 What is the current status for building android apps in D? I 
 would like to create simple graphic based apps but don't wanna 
 get bogged down in trying to get car moving without any wheels.


 Should all work, but nothing other than small apps have been 
 tested.  Try the latest beta, which I just put up:

 http://forum.dlang.org/post/xetfqojxijgobisfacvx forum.dlang.org

 If you want something more substantive than my ports of the 
 NDK's sample apps, check out Vadim's Tetris app, which I spent 
 half an hour playing on my phone, :) or his minecraft-like demo 
 (click on the sourceforge link from his forum post to get the 
 apps):

 http://forum.dlang.org/thread/cdekkumjynhqoxvmgjze forum.dlang.org

 Let me know if you have any questions or problems.


Thanks, hopefully it works. Had to upgrade to win10 aniversary 
and it destroyed my system so I am now in the process of getting 
it back to normal. Hopefully this Bash on Ubuntu is worth it and 
everything works as advertised...
Dec 29 2016
prev sibling next sibling parent reply Ignacious <I.D.T ProjectMaya.com> writes:
On Thursday, 29 December 2016 at 10:14:53 UTC, Joakim wrote:

 On Wednesday, 28 December 2016 at 23:33:57 UTC, Ignacious wrote:

 What is the current status for building android apps in D? I 
 would like to create simple graphic based apps but don't wanna 
 get bogged down in trying to get car moving without any wheels.


 Should all work, but nothing other than small apps have been 
 tested.  Try the latest beta, which I just put up:

 http://forum.dlang.org/post/xetfqojxijgobisfacvx forum.dlang.org

 If you want something more substantive than my ports of the 
 NDK's sample apps, check out Vadim's Tetris app, which I spent 
 half an hour playing on my phone, :) or his minecraft-like demo 
 (click on the sourceforge link from his forum post to get the 
 apps):

 http://forum.dlang.org/thread/cdekkumjynhqoxvmgjze forum.dlang.org

 Let me know if you have any questions or problems.


Is there any way to get a package that works for windows? While 
the steps don't seem too difficult to do, things never go well 
for me(something always breaks... always!)

did install the linux subsystem but... seems like it would be 
easier for you to compile a binary and upload it... since you 
know what you are doing and have everything at hand already...

At least that gives me(and others) the ability to try to build 
the examples and see how it works and all that... then I can go 
through all the trouble of building the compiler myself if it 
seems worth it rather than wasting time.
Dec 30 2016
next sibling parent reply Ignacious <I.D.T ProjectMaya.com> writes:
On Saturday, 31 December 2016 at 05:52:00 UTC, Ignacious wrote:

 On Thursday, 29 December 2016 at 10:14:53 UTC, Joakim wrote:

 [...]


 Is there any way to get a package that works for windows? While 
 the steps don't seem too difficult to do, things never go well 
 for me(something always breaks... always!)

 did install the linux subsystem but... seems like it would be 
 easier for you to compile a binary and upload it... since you 
 know what you are doing and have everything at hand already...

 At least that gives me(and others) the ability to try to build 
 the examples and see how it works and all that... then I can go 
 through all the trouble of building the compiler myself if it 
 seems worth it rather than wasting time.


I see these:

https://github.com/joakim-noah/android/releases

Seems the two archives are identical though except the libs?

Is this what I use to compile the examples?
Dec 30 2016
parent Ignacious <I.D.T ProjectMaya.com> writes:
On Saturday, 31 December 2016 at 06:33:10 UTC, Ignacious wrote:

 On Saturday, 31 December 2016 at 05:52:00 UTC, Ignacious wrote:

 On Thursday, 29 December 2016 at 10:14:53 UTC, Joakim wrote:

 [...]


 Is there any way to get a package that works for windows? 
 While the steps don't seem too difficult to do, things never 
 go well for me(something always breaks... always!)

 did install the linux subsystem but... seems like it would be 
 easier for you to compile a binary and upload it... since you 
 know what you are doing and have everything at hand already...

 At least that gives me(and others) the ability to try to build 
 the examples and see how it works and all that... then I can 
 go through all the trouble of building the compiler myself if 
 it seems worth it rather than wasting time.


 I see these:

 https://github.com/joakim-noah/android/releases

 Seems the two archives are identical though except the libs?

 Is this what I use to compile the examples?


nvm mind, I guess I accidentally extracted the same archive 
thinking it was the other.

so, essentially these are the two different compilers for the two 
different android architectures?
Dec 30 2016
prev sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Saturday, 31 December 2016 at 05:52:00 UTC, Ignacious wrote:

 On Thursday, 29 December 2016 at 10:14:53 UTC, Joakim wrote:

 On Wednesday, 28 December 2016 at 23:33:57 UTC, Ignacious 
 wrote:

 What is the current status for building android apps in D? I 
 would like to create simple graphic based apps but don't 
 wanna get bogged down in trying to get car moving without any 
 wheels.


 Should all work, but nothing other than small apps have been 
 tested.  Try the latest beta, which I just put up:

 http://forum.dlang.org/post/xetfqojxijgobisfacvx forum.dlang.org

 If you want something more substantive than my ports of the 
 NDK's sample apps, check out Vadim's Tetris app, which I spent 
 half an hour playing on my phone, :) or his minecraft-like 
 demo (click on the sourceforge link from his forum post to get 
 the apps):

 http://forum.dlang.org/thread/cdekkumjynhqoxvmgjze forum.dlang.org

 Let me know if you have any questions or problems.


 Is there any way to get a package that works for windows? While 
 the steps don't seem too difficult to do, things never go well 
 for me(something always breaks... always!)

 did install the linux subsystem but... seems like it would be 
 easier for you to compile a binary and upload it... since you 
 know what you are doing and have everything at hand already...

 At least that gives me(and others) the ability to try to build 
 the examples and see how it works and all that... then I can go 
 through all the trouble of building the compiler myself if it 
 seems worth it rather than wasting time.


Sorry, I haven't used Windows in more than a year, ever since my 
ultrabook died.  I've gone full Android since then, which is why 
it is easier for me to provide a native Android compiler than a 
Windows cross-compiler. :) I'm currently typing this message out 
on an Android 5.1" smartphone, propped up on a cheap Chinese 
tablet stand in front of me and hooked up to a full USB keyboard.

In any case, you should be able to use the linux build I provide, 
as you later found.

On Saturday, 31 December 2016 at 06:48:12 UTC, Ignacious wrote:

 On Saturday, 31 December 2016 at 06:33:10 UTC, Ignacious wrote:

 On Saturday, 31 December 2016 at 05:52:00 UTC, Ignacious wrote:

 On Thursday, 29 December 2016 at 10:14:53 UTC, Joakim wrote:

 [...]




 

 I see these:

 https://github.com/joakim-noah/android/releases

 Seems the two archives are identical though except the libs?

 Is this what I use to compile the examples?


 nvm mind, I guess I accidentally extracted the same archive 
 thinking it was the other.

 so, essentially these are the two different compilers for the 
 two different android architectures?


As mentioned at the top of the release, the first is a native 
Android compiler, meaning you use it on an Android tablet or 
smartphone.  The second is a linux cross-compiler, meaning you 
need a linux/x64 shell from which you cross-compile to 
Android/ARM.

On Saturday, 31 December 2016 at 08:05:42 UTC, Ignacious wrote:

 Ok, so I installed
 ldc2-android-arm-1.1.0-beta4-linux-x86_64.tar.xz

 in to ldcandroid

 and tried running

 ./bin/ldc2 -c test.d

 I get the error.

 ./bin/ldc2: error while loading shared libraries: 
 libconfig.so.9: cannot open shared object file: No such file or 
 directory

 Searched the file system for libconfig and found nothing so I 
 did

 sudo apt-get install libconfig++9

 which installed it under lxss\rootfs\usr\lib\x86_64-linux-gnu

 It shows up when I do

 sudo ldconfig -v

 /usr/lib/x86_64-linux-gnu:
 libconfig++.so.9 -> libconfig++.so.9.1.3

 I tried adding this:

 export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu

 But still same issue.

 Any ideas how to fix this?


Can you try

sudo apt-get install libconfig9

I don't know if that will install something different, but it's 
the command I see others using online.  Otherwise, check if the 
libconfig++9 package you installed included libconfig.so.9, which 
is what ldc is linked against.  If not, install the package that 
provides that library.  The wiki mentions installing 
libconfig-dev, you could always just install that if nothing else 
works.

Let me know if you run into any other problems.  The Win10 
support is brand new, just added this week, so we don't have much 
experience with it.
Dec 31 2016
parent reply Ignacious <I.D.T ProjectMaya.com> writes:
 Can you try

 sudo apt-get install libconfig9

 I don't know if that will install something different, but it's 
 the command I see others using online.  Otherwise, check if the 
 libconfig++9 package you installed included libconfig.so.9, 
 which is what ldc is linked against.  If not, install the 
 package that provides that library.  The wiki mentions 
 installing libconfig-dev, you could always just install that if 
 nothing else works.



That is what I used to get it on there in the first place... but 
the ldc compiler still could not find it.

The problem seems to be where ldc2 is looking for libconfig.so.9 
rather than it being installed or not.

How do I either know where it is looking for where to put it?
Jan 01 2017
parent reply Joakim <dlang joakim.fea.st> writes:
On Sunday, 1 January 2017 at 09:34:24 UTC, Ignacious wrote:

 Can you try

 sudo apt-get install libconfig9

 I don't know if that will install something different, but 
 it's the command I see others using online.  Otherwise, check 
 if the libconfig++9 package you installed included 
 libconfig.so.9, which is what ldc is linked against.  If not, 
 install the package that provides that library.  The wiki 
 mentions installing libconfig-dev, you could always just 
 install that if nothing else works.



 That is what I used to get it on there in the first place... 
 but the ldc compiler still could not find it.

 The problem seems to be where ldc2 is looking for 
 libconfig.so.9 rather than it being installed or not.

 How do I either know where it is looking for where to put it?


You said you installed libconfig++9, which an apt search shows me 
is a different package than libconfig9, that includes a library 
named differently.  As I said, are you sure that particular 
libconfig.so.9 library is installed?

If it is, manually adding its path to LD_LIBRARY_PATH is the way 
to make sure it's found.
Jan 01 2017
parent reply Ignacious <I.D.T ProjectMaya.com> writes:
On Monday, 2 January 2017 at 03:08:10 UTC, Joakim wrote:

 On Sunday, 1 January 2017 at 09:34:24 UTC, Ignacious wrote:

 Can you try

 sudo apt-get install libconfig9

 I don't know if that will install something different, but 
 it's the command I see others using online.  Otherwise, check 
 if the libconfig++9 package you installed included 
 libconfig.so.9, which is what ldc is linked against.  If not, 
 install the package that provides that library.  The wiki 
 mentions installing libconfig-dev, you could always just 
 install that if nothing else works.



 That is what I used to get it on there in the first place... 
 but the ldc compiler still could not find it.

 The problem seems to be where ldc2 is looking for 
 libconfig.so.9 rather than it being installed or not.

 How do I either know where it is looking for where to put it?


 You said you installed libconfig++9, which an apt search shows 
 me is a different package than libconfig9, that includes a 
 library named differently.  As I said, are you sure that 
 particular libconfig.so.9 library is installed?

 If it is, manually adding its path to LD_LIBRARY_PATH is the 
 way to make sure it's found.


Ok, I didn't realize they were different packages.

I now get the error

./bin/ldmd2: error while loading shared libraries: 
libncursesw.so.6: cannot open shared object file: No such file or 
directory

and trying to install libncursesw is missing. I tried installing 
libncurses5 and it worked, but, of course, not version 6 or 
whatever. tried various things... nothing works.

./bin/ldc2: error while loading shared libraries: 
libncursesw.so.6: cannot open shared object file: No such file or 
directory

I downloaded the sources. I had to install gcc, make, then I did 
./configure --enable-widec 
(http://arstechnica.com/civis/viewtopic.php?f=20&t=1161942), then 
ran make.. I end up getting the errors

make[1]: Leaving directory `/mnt/b/c/test'
cd misc && make DESTDIR="" all
make[1]: Entering directory `/mnt/b/c/misc'
WHICH_XTERM=xterm-new \
         ticdir=/usr/share/terminfo \
         /bin/sh ./gen_edit.sh >run_tic.sed
echo '** adjusting tabset paths'
** adjusting tabset paths
sed -f run_tic.sed ../misc/terminfo.src >terminfo.tmp
make[1]: Leaving directory `/mnt/b/c/misc'
cd c++ && make DESTDIR="" all
make[1]: Entering directory `/mnt/b/c/c++'
cp ./etip.h.in etip.h
sh ./edit_cfg.sh ../include/ncurses_cfg.h etip.h
substituting autoconf'd values from ../include/ncurses_cfg.h into 
etip.h
... CPP_HAS_PARAM_INIT 0
... CPP_HAS_STATIC_CAST 0
... ETIP_NEEDS_MATH_EXCEPTION 0
... ETIP_NEEDS_MATH_H 0
... HAVE_BUILTIN_H 0
... HAVE_GPP_BUILTIN_H 0
... HAVE_GXX_BUILTIN_H 0
... HAVE_IOSTREAM 0
... HAVE_TYPEINFO 0
... HAVE_VALUES_H 0
... IOSTREAM_NAMESPACE 0
cd ../objects;   -I../c++ -I../include -I. -DHAVE_CONFIG_H  
-D_GNU_SOURCE -DNDEBUG -I. -I../include  -c ../c++/cursesf.cc
/bin/sh: 1: -I../c++: not found
make[1]: *** [../objects/cursesf.o] Error 127
make[1]: Leaving directory `/mnt/b/c/c++'
make: *** [all] Error 2

So, now I do not know what to do next.


Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package libncurses6

(This is why I hate working linux, so much obfuscation... so many 
potential points of failure)

Also, once I go through all this trouble, I have to do it again 
for the arm verson(using x86-64 ldc)? Can I install on the same 
system or will the libraries conflict and I'll have to go through 
all this mess again?
Jan 02 2017
parent reply Joakim <dlang joakim.fea.st> writes:
On Monday, 2 January 2017 at 11:47:52 UTC, Ignacious wrote:

 On Monday, 2 January 2017 at 03:08:10 UTC, Joakim wrote:

 On Sunday, 1 January 2017 at 09:34:24 UTC, Ignacious wrote:

 Can you try

 sudo apt-get install libconfig9

 I don't know if that will install something different, but 
 it's the command I see others using online.  Otherwise, 
 check if the libconfig++9 package you installed included 
 libconfig.so.9, which is what ldc is linked against.  If 
 not, install the package that provides that library.  The 
 wiki mentions installing libconfig-dev, you could always 
 just install that if nothing else works.



 That is what I used to get it on there in the first place... 
 but the ldc compiler still could not find it.

 The problem seems to be where ldc2 is looking for 
 libconfig.so.9 rather than it being installed or not.

 How do I either know where it is looking for where to put it?


 You said you installed libconfig++9, which an apt search shows 
 me is a different package than libconfig9, that includes a 
 library named differently.  As I said, are you sure that 
 particular libconfig.so.9 library is installed?

 If it is, manually adding its path to LD_LIBRARY_PATH is the 
 way to make sure it's found.


 Ok, I didn't realize they were different packages.

 I now get the error

 ./bin/ldmd2: error while loading shared libraries: 
 libncursesw.so.6: cannot open shared object file: No such file 
 or directory

 and trying to install libncursesw is missing. I tried 
 installing libncurses5 and it worked, but, of course, not 
 version 6 or whatever. tried various things... nothing works.

 ./bin/ldc2: error while loading shared libraries: 
 libncursesw.so.6: cannot open shared object file: No such file 
 or directory

 I downloaded the sources. I had to install gcc, make, then I 
 did ./configure --enable-widec 
 (http://arstechnica.com/civis/viewtopic.php?f=20&t=1161942), 
 then ran make.. I end up getting the errors

 make[1]: Leaving directory `/mnt/b/c/test'
 cd misc && make DESTDIR="" all
 make[1]: Entering directory `/mnt/b/c/misc'
 WHICH_XTERM=xterm-new \
         ticdir=/usr/share/terminfo \
         /bin/sh ./gen_edit.sh >run_tic.sed
 echo '** adjusting tabset paths'
 ** adjusting tabset paths
 sed -f run_tic.sed ../misc/terminfo.src >terminfo.tmp
 make[1]: Leaving directory `/mnt/b/c/misc'
 cd c++ && make DESTDIR="" all
 make[1]: Entering directory `/mnt/b/c/c++'
 cp ./etip.h.in etip.h
 sh ./edit_cfg.sh ../include/ncurses_cfg.h etip.h
 substituting autoconf'd values from ../include/ncurses_cfg.h 
 into etip.h
 ... CPP_HAS_PARAM_INIT 0
 ... CPP_HAS_STATIC_CAST 0
 ... ETIP_NEEDS_MATH_EXCEPTION 0
 ... ETIP_NEEDS_MATH_H 0
 ... HAVE_BUILTIN_H 0
 ... HAVE_GPP_BUILTIN_H 0
 ... HAVE_GXX_BUILTIN_H 0
 ... HAVE_IOSTREAM 0
 ... HAVE_TYPEINFO 0
 ... HAVE_VALUES_H 0
 ... IOSTREAM_NAMESPACE 0
 cd ../objects;   -I../c++ -I../include -I. -DHAVE_CONFIG_H  
 -D_GNU_SOURCE -DNDEBUG -I. -I../include  -c ../c++/cursesf.cc
 /bin/sh: 1: -I../c++: not found
 make[1]: *** [../objects/cursesf.o] Error 127
 make[1]: Leaving directory `/mnt/b/c/c++'
 make: *** [all] Error 2

 So, now I do not know what to do next.


 Reading package lists... Done
 Building dependency tree
 Reading state information... Done
 E: Unable to locate package libncurses6

 (This is why I hate working linux, so much obfuscation... so 
 many potential points of failure)


Yeah, not a good idea to build from source yourself.  Try the 
advice here, ie see if you can install a package with that 
library or just symlink to the older library if not:

http://askubuntu.com/questions/771047/erlang-error-while-loading-shared-libraries-libncursesw-so-6

Every system has these problems, whether Windows, linux, or OS X. 
Linux makes it really easy to install packages and libraries, but 
then you can hit this issue where Debian/Ubuntu doesn't provide 
the latest versions of packages like Arch does, which is where I 
compiled the cross-compiler.


 Also, once I go through all this trouble, I have to do it again 
 for the arm verson(using x86-64 ldc)? Can I install on the same 
 system or will the libraries conflict and I'll have to go 
 through all this mess again?


I'm not sure what you mean, there is no other ARM version.  All 
you have to do is download the cross-compiler and run it.  The 
cross-compiler is a linux/x64 binary that comes with a 
pre-compiled standard library for ARM.  Once you can run this 
cross-compiler build I provided, by setting up the needed 
libraries, you should be able to build Android binaries or apks 
just by using the cross-compiler, by following these instructions:

http://wiki.dlang.org/Build_LDC_for_Android#Build_a_command-line_executable
http://wiki.dlang.org/Build_LDC_for_Android#Build_a_sample_OpenGL_Android_app_ported_to_D

However, you will also want to install the Android SDK for 
Windows, which requires Java, if you want to build an apk in the 
usual way, as mentioned in the wiki:

http://developer.android.com/sdk/index.html

Alternately, you could package an apk from scratch using OpenSSL, 
if you don't want all that SDK crap like me:

https://github.com/termux/termux-packages/issues/63#issuecomment-184115581

Unfortunately, there is no dead-simple way to get this Android 
toolchain setup.
Jan 02 2017
parent reply Ignacious <I.D.T ProjectMaya.com> writes:
 Yeah, not a good idea to build from source yourself.  Try the 
 advice here, ie see if you can install a package with that 
 library or just symlink to the older library if not:

 http://askubuntu.com/questions/771047/erlang-error-while-loading-shared-libraries-libncursesw-so-6


Well, the only way to get it to work is rename 5.9 ver to 6.0, 
but then now I get the error


bin/ldmd2: error while loading shared libraries: 
libncursesw.so.6: cannot open shared object file: No such file or 
directory

bin/ldmd2: error while loading shared libraries: 
libncursesw.so.6: cannot open shared object file: No such file or 
directory

bin/ldmd2: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version 
`GLIBCXX_3.4.21' not found (required by bin/ldmd2)

bin/ldc2: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version 
`GLIBCXX_3.4.20' not found (required by bin/ldc2)
bin/ldc2: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version 
`GLIBCXX_3.4.21' not found (required by bin/ldc2)

I followed this page:

http://askubuntu.com/questions/575505/glibcxx-3-4-20-not-found-how-to-fix-this-error

and now I get the error


bin/ldc2: relocation error: bin/ldc2: symbol 
_ZNKSt3_V214error_category10_M_messageB5cxx11Ei, version 
GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time 
reference

even though

strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBCXX_DEBUG_MESSAGE_LENGTH

I suppose it will be easier to install a real ubuntu distro 
rather than relying on windows? All these issues seem to be 
related to outdated versions?

Distributor ID: Ubuntu
Description:    Ubuntu 14.04.5 LTS
Release:        14.04
Codename:       trusty
Jan 08 2017
parent reply Joakim <dlang joakim.fea.st> writes:
On Sunday, 8 January 2017 at 19:58:06 UTC, Ignacious wrote:

 I suppose it will be easier to install a real ubuntu distro 
 rather than relying on windows? All these issues seem to be 
 related to outdated versions?

 Distributor ID: Ubuntu
 Description:    Ubuntu 14.04.5 LTS
 Release:        14.04
 Codename:       trusty


I doubt that'd work either as Debian just uses older packages.  
Your best bet may be to just compile ldc yourself, by following 
the instructions on the wiki.
Jan 08 2017
parent reply Ignacious <I.D.T ProjectMaya.com> writes:
On Sunday, 8 January 2017 at 20:34:21 UTC, Joakim wrote:

 On Sunday, 8 January 2017 at 19:58:06 UTC, Ignacious wrote:

 I suppose it will be easier to install a real ubuntu distro 
 rather than relying on windows? All these issues seem to be 
 related to outdated versions?

 Distributor ID: Ubuntu
 Description:    Ubuntu 14.04.5 LTS
 Release:        14.04
 Codename:       trusty


 I doubt that'd work either as Debian just uses older packages.  
 Your best bet may be to just compile ldc yourself, by following 
 the instructions on the wiki.


Well, I finally got it to upgrade to 16.. when I run ldc2 or 
ldmd2 I get the following errors

/usr/bin/ld: test.o: Relocations in generic ELF (EM: 40)
/usr/bin/ld: test.o: Relocations in generic ELF (EM: 40)
/usr/bin/ld: test.o: Relocations in generic ELF (EM: 40)
/usr/bin/ld: test.o: Relocations in generic ELF (EM: 40)
/usr/bin/ld: test.o: Relocations in generic ELF (EM: 40)
/usr/bin/ld: test.o: Relocations in generic ELF (EM: 40)
/usr/bin/ld: test.o: Relocations in generic ELF (EM: 40)
test.o: error adding symbols: File in wrong format
collect2: error: ld returned 1 exit status
Error: /usr/bin/gcc failed with status: 1

test is just a simple hello world.




Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
5.4.0-6ubuntu1~16.04.4' 
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ 
--prefix=/usr --program-suffix=-5 --enable-shared 
--enable-linker-build-id --libexecdir=/usr/lib 
--without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ 
--enable-clocale=gnu --enable-libstdcxx-debug 
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new 
--enable-gnu-unique-object --disable-vtable-verify 
--enable-libmpx --enable-plugin --with-system-zlib 
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre 
--enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 
--with-arch-directory=amd64 
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc 
--enable-multiarch --disable-werror --with-arch-32=i686 
--with-abi=m64 --with-multilib-list=m32,m64,mx32 
--enable-multilib --with-tune=generic --enable-checking=release 
--build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)


Not sure what is going on, of course ;) So much BS just to do 
something that is suppose to be simple ;)


test.d



void main()
{

}

here is test.o

http://pastebin.com/NRrKgKtb

Any ideas?
Jan 08 2017
parent reply Joakim <dlang joakim.fea.st> writes:
On Sunday, 8 January 2017 at 21:52:01 UTC, Ignacious wrote:

 Not sure what is going on, of course ;) So much BS just to do 
 something that is suppose to be simple ;)


 test.d



 void main()
 {

 }

 here is test.o

 http://pastebin.com/NRrKgKtb

 Any ideas?


Oh, that's easy: install the NDK too, as shown on the wiki.  You 
need the linker that supports ARM from the NDK.  Follow the 
instructions from the wiki to compile and link the binary, simply 
having ldc do everything won't work.

Cross-compiler toolchains are never simple, consider yourself 
lucky for having gotten off easy. :)
Jan 08 2017
parent reply Ignacious <I.D.T ProjectMaya.com> writes:
On Sunday, 8 January 2017 at 22:19:31 UTC, Joakim wrote:

 On Sunday, 8 January 2017 at 21:52:01 UTC, Ignacious wrote:

 Not sure what is going on, of course ;) So much BS just to do 
 something that is suppose to be simple ;)


 test.d



 void main()
 {

 }

 here is test.o

 http://pastebin.com/NRrKgKtb

 Any ideas?


 Oh, that's easy: install the NDK too, as shown on the wiki.  
 You need the linker that supports ARM from the NDK.  Follow the 
 instructions from the wiki to compile and link the binary, 
 simply having ldc do everything won't work.


Ok, after executing

$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 test.o lib/libphobos2-ldc.a 
lib/libdruntime-ldc.a -o test

I get a test elf file with no errors(although 2.5MB for a hello 
world).

I had to do the chmod 755 test

then

./test

to get any output. Before that no output and no errors so wasn't 
sure what as going on.

Looks like everything is working! ;)

Seems like someone really needs to put some time in to getting 
all this stuff organized and situated

Maybe the D language foundation can push some money towards it to 
get it started off on the right foot?

I'll try to get some of the opengl examples on your repository to 
see if they work soon.



 Cross-compiler toolchains are never simple, consider yourself 
 lucky for having gotten off easy. :)


I realize things are difficult but it's people that make it that 
way ;) Life would be so much simpler if people would just 
properly document stuff exactly(or, rather, do what they are 
suppose to do). (Even windows seems to love to forget to put in 
descriptions of services, tasks, application descriptions, etc).

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.
Jan 08 2017
parent reply Joakim <dlang joakim.fea.st> writes:
On Monday, 9 January 2017 at 00:40:35 UTC, Ignacious wrote:

 On Sunday, 8 January 2017 at 22:19:31 UTC, Joakim wrote:

 On Sunday, 8 January 2017 at 21:52:01 UTC, Ignacious wrote:

 Not sure what is going on, of course ;) So much BS just to do 
 something that is suppose to be simple ;)


 test.d



 void main()
 {

 }

 here is test.o

 http://pastebin.com/NRrKgKtb

 Any ideas?


 Oh, that's easy: install the NDK too, as shown on the wiki.  
 You need the linker that supports ARM from the NDK.  Follow 
 the instructions from the wiki to compile and link the binary, 
 simply having ldc do everything won't work.


 Ok, after executing

 $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 test.o lib/libphobos2-ldc.a 
 lib/libdruntime-ldc.a -o test

 I get a test elf file with no errors(although 2.5MB for a hello 
 world).

 I had to do the chmod 755 test

 then

 ./test

 to get any output. Before that no output and no errors so 
 wasn't sure what as going on.

 Looks like everything is working! ;)


Good to hear it finally works. :D


 Seems like someone really needs to put some time in to getting 
 all this stuff organized and situated

 Maybe the D language foundation can push some money towards it 
 to get it started off on the right foot?

 I'll try to get some of the opengl examples on your repository 
 to see if they work soon.


I don't think money is the issue as much as people like you 
trying it on your own platform and documenting any problems you 
find.


 Cross-compiler toolchains are never simple, consider yourself 
 lucky for having gotten off easy. :)


 I realize things are difficult but it's people that make it 
 that way ;) Life would be so much simpler if people would just 
 properly document stuff exactly(or, rather, do what they are 
 suppose to do). (Even windows seems to love to forget to put in 
 descriptions of services, tasks, application descriptions, etc).


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.


 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.
Jan 09 2017
next sibling parent reply Ignacious <I.D.T ProjectMaya.com> writes:
On Monday, 9 January 2017 at 08:28:04 UTC, Joakim wrote:

 On Monday, 9 January 2017 at 00:40:35 UTC, Ignacious wrote:

 On Sunday, 8 January 2017 at 22:19:31 UTC, Joakim wrote:

 On Sunday, 8 January 2017 at 21:52:01 UTC, Ignacious wrote:

 Not sure what is going on, of course ;) So much BS just to 
 do something that is suppose to be simple ;)


 test.d



 void main()
 {

 }

 here is test.o

 http://pastebin.com/NRrKgKtb

 Any ideas?


 Oh, that's easy: install the NDK too, as shown on the wiki.  
 You need the linker that supports ARM from the NDK.  Follow 
 the instructions from the wiki to compile and link the 
 binary, simply having ldc do everything won't work.


 Ok, after executing

 $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 test.o
lib/libphobos2-ldc.a lib/libdruntime-ldc.a -o test

 I get a test elf file with no errors(although 2.5MB for a 
 hello world).

 I had to do the chmod 755 test

 then

 ./test

 to get any output. Before that no output and no errors so 
 wasn't sure what as going on.

 Looks like everything is working! ;)


 Good to hear it finally works. :D


 Seems like someone really needs to put some time in to getting 
 all this stuff organized and situated

 Maybe the D language foundation can push some money towards it 
 to get it started off on the right foot?

 I'll try to get some of the opengl examples on your repository 
 to see if they work soon.


 I don't think money is the issue as much as people like you 
 trying it on your own platform and documenting any problems you 
 find.


ssshhh! Don't say that! Money always help!!! ;)


 Cross-compiler toolchains are never simple, consider yourself 
 lucky for having gotten off easy. :)


 I realize things are difficult but it's people that make it 
 that way ;) Life would be so much simpler if people would just 
 properly document stuff exactly(or, rather, do what they are 
 suppose to do). (Even windows seems to love to forget to put 
 in descriptions of services, tasks, application descriptions, 
 etc).


 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! ;)



 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.

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.

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 will try to do a better job of documenting my progress now that 
I have some faith ;) But right now I'm more of the horse rather 
than the guy trying to show him where the water is.
Jan 09 2017
parent reply Joakim <dlang joakim.fea.st> writes:
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



 /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


 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.
Jan 09 2017
parent reply Ignacious <I.D.T ProjectMaya.com> writes:
Well, I posed a reply but I guess it didn't get though ;/

I'm only suing android-x86 because I thought it would be easier 
to test/debug. My device is a cortex-arm7.

Two questions I have:

1. In the command lines present there is a lot of use of `x86`. I 
used them to compile the hello world for my device and it worked 
so I'm a bit confused. I realize there is the x86 binaries for 
compiling and then the binaries that are compiled to but not sure 
what is what.

2. I downloaded the native_app_glue.d and tried to compile it. It 
imports jni.d which I found in hello-jni and I copied that to the 
android folder and was able to compile it using effectively the 
same command line I used to compile the working hello world code.

but when I try to then use it to compile the hello-jni sample I 
get that it is an invalid format and many ELF relocation errors.

Could you send me your working native_app_glue.o(if for the 
cortex-arm7 or try to compile it for both cortex-arm7 and 
x86/x64) or explain to me what is the issue with linking it in 
and how to fix it?


cmdline that compiles android_native_app_glue.d
bin/ldc2 -m32 -shared  -Iandroid -c android_native_app_glue.d

(tried with -m64 and without either)

cmdline trying to compile hello-jni.

  $NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/clang 
-Wl,-soname,libhello-jni.so -shared 
--sysroot=$NDK/platforms/android-9/arch-x86 
../obj/local/x86/objs-debug/hello-jni/hello-jni.o 
../android_native_app_glue.o -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/libhello-jni.so

which gives the errors

....
/usr/bin/ld.bfd: ../android_native_app_glue.o: Relocations in 
generic ELF (EM: 40)
/usr/bin/ld.bfd: ../android_native_app_glue.o: Relocations in 
generic ELF (EM: 40)
/usr/bin/ld.bfd: ../android_native_app_glue.o: Relocations in 
generic ELF (EM: 40)
../android_native_app_glue.o: error adding symbols: File in wrong 
format
clang: error: linker command failed with exit code 1 (use -v to 
see invocation)

It might be better to wait for you to finish your build setup 
which might resolve all these problems and be more robust(I'd 
like to be able to easily build for different platforms(for 
testing on VM and device). But if all I need to do is get the 
android_native_app_glue to work to run full fledged apps, then It 
seems I'm close? (just need to compile it to the correct format?)


Thanks for all the help!
Jan 10 2017
parent reply Joakim <dlang joakim.fea.st> writes:
On Tuesday, 10 January 2017 at 18:48:17 UTC, Ignacious wrote:

 Well, I posed a reply but I guess it didn't get though ;/

 I'm only suing android-x86 because I thought it would be easier 
 to test/debug. My device is a cortex-arm7.


It's probably not easier, and in any case, android-x86 won't be 
supported, largely because I don't have any working x86 devices.


 Two questions I have:

 1. In the command lines present there is a lot of use of `x86`.


There shouldn't be when compiling for ARM.  The instructions for 
ARM only have it because of the path where the cross-compiler 
toolchain is stored, in a directory called 
toolchains/llvm/prebuilt/linux-x86_64/ because that's the OS and 
CPU architecture where you can run the cross-compiler.


 I used them to compile the hello world for my device and it 
 worked so I'm a bit confused. I realize there is the x86 
 binaries for compiling and then the binaries that are compiled 
 to but not sure what is what.


You are cross-compiling from linux (even though it's really a 
linux shell running in Windows) with the x86 or x86_64 CPU 
architecture to Android with the ARM CPU architecture.  As such 
the cross-compiler itself is an x86_64 binary, but produces an 
ARM object file and binary.  You have to be careful to set up the 
toolchain right or you will produce files for the wrong 
architecture.


 2. I downloaded the native_app_glue.d and tried to compile it. 
 It imports jni.d which I found in hello-jni and I copied that 
 to the android folder and was able to compile it using 
 effectively the same command line I used to compile the working 
 hello world code.


I'm not sure why you are downloading and moving around these 
individual files.  They should all be in my android repository, 
which both pages of instructions tell you to clone.


 but when I try to then use it to compile the hello-jni sample I 
 get that it is an invalid format and many ELF relocation errors.

 Could you send me your working native_app_glue.o(if for the 
 cortex-arm7 or try to compile it for both cortex-arm7 and 
 x86/x64) or explain to me what is the issue with linking it in 
 and how to fix it?


No.  I'm not going to support Android/x86 and all the 
instructions are there for Android/ARM.


 cmdline that compiles android_native_app_glue.d
 bin/ldc2 -m32 -shared  -Iandroid -c android_native_app_glue.d

 (tried with -m64 and without either)


This won't work because my latest build of the ldc cross-compiler 
will try to compile for ARM by default.


 cmdline trying to compile hello-jni.

  $NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/clang 
 -Wl,-soname,libhello-jni.so -shared 
 --sysroot=$NDK/platforms/android-9/arch-x86 
 ../obj/local/x86/objs-debug/hello-jni/hello-jni.o 
 ../android_native_app_glue.o -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/libhello-jni.so

 which gives the errors

 ....
 /usr/bin/ld.bfd: ../android_native_app_glue.o: Relocations in 
 generic ELF (EM: 40)
 /usr/bin/ld.bfd: ../android_native_app_glue.o: Relocations in 
 generic ELF (EM: 40)
 /usr/bin/ld.bfd: ../android_native_app_glue.o: Relocations in 
 generic ELF (EM: 40)
 ../android_native_app_glue.o: error adding symbols: File in 
 wrong format
 clang: error: linker command failed with exit code 1 (use -v to 
 see invocation)


It's telling you that android_native_app_glue.o is the wrong 
format, likely ARM as I noted above.  You can check the format 
with this command:

file android_native_app_glue.o

Since you're trying to create a binary for Android/x86, it cannot 
use the ARM object file to build it.


 It might be better to wait for you to finish your build setup 
 which might resolve all these problems and be more robust(I'd 
 like to be able to easily build for different platforms(for 
 testing on VM and device).


There is nothing to wait for, as I will not support Android/x86, 
certainly not anytime soon.


 But if all I need to do is get the android_native_app_glue to 
 work to run full fledged apps, then It seems I'm close? (just 
 need to compile it to the correct format?)


It may not take much more to get it working, as I did first try 
ldc with Android/x86 and left that support in.  However, it 
hasn't been tested in more than a year and so probably will 
require some fixing up.  If you want to look into that, you're on 
your own.
Jan 10 2017
parent reply Ignacious <I.D.T ProjectMaya.com> writes:
On Wednesday, 11 January 2017 at 03:49:42 UTC, Joakim wrote:

 On Tuesday, 10 January 2017 at 18:48:17 UTC, Ignacious wrote:

 [...]


 It's probably not easier, and in any case, android-x86 won't be 
 supported, largely because I don't have any working x86 devices.

 [...]


Ok, well the x86 thing wasn't my idea! It seems I was using the 
wrong build command for trying to compile the examples.

In any case, I'll just wait until things get working a bit 
better. I'd suggest you put, in the title of the page, a bit more 
information. I didn't realize I was looking at an old 
version(which looks too similar to the new one).
Jan 11 2017
parent Andre Pany <andre s-e-a-p.de> writes:
On Wednesday, 11 January 2017 at 21:13:07 UTC, Ignacious wrote:

 On Wednesday, 11 January 2017 at 03:49:42 UTC, Joakim wrote:

 On Tuesday, 10 January 2017 at 18:48:17 UTC, Ignacious wrote:

 [...]


 It's probably not easier, and in any case, android-x86 won't 
 be supported, largely because I don't have any working x86 
 devices.

 [...]


 Ok, well the x86 thing wasn't my idea! It seems I was using the 
 wrong build command for trying to compile the examples.

 In any case, I'll just wait until things get working a bit 
 better. I'd suggest you put, in the title of the page, a bit 
 more information. I didn't realize I was looking at an old 
 version(which looks too similar to the new one).


I am currently preparing a repository on dockerhub which contains 
the newest ldc with android support and the Android NDK. While 
these two applications run in a container you only have to 
install the Android SDK on your host machine. The dockerfile is 
in an early state, I will create an anouncememt when it is 
finished. You can already have a look 
https://hub.docker.com/r/andre2007/ldc-android/

Kind regards
Andre
Jan 14 2017
prev sibling parent Ignacious <I.D.T ProjectMaya.com> writes:
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?

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

(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)


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. 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



/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
)

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.


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


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?

Basically we have andorid_native_app_glue.c which we modify with 
rt_init and rt_term. We have a d file of that which I don't know 
what to do with. I see that somewhere in the compiling of the of 
the sample file that it is used but I'm unsure of what is what 
and how to go about getting android_native_app_glue.a(is it the d 
version compiled, something that comes from the ndk, or what?)



(sorry for the mess, was trying stuff as I went along)
Jan 09 2017
prev sibling parent Ignacious <I.D.T ProjectMaya.com> writes:
On Thursday, 29 December 2016 at 10:14:53 UTC, Joakim wrote:

 On Wednesday, 28 December 2016 at 23:33:57 UTC, Ignacious wrote:

 What is the current status for building android apps in D? I 
 would like to create simple graphic based apps but don't wanna 
 get bogged down in trying to get car moving without any wheels.


 Should all work, but nothing other than small apps have been 
 tested.  Try the latest beta, which I just put up:

 http://forum.dlang.org/post/xetfqojxijgobisfacvx forum.dlang.org

 If you want something more substantive than my ports of the 
 NDK's sample apps, check out Vadim's Tetris app, which I spent 
 half an hour playing on my phone, :) or his minecraft-like demo 
 (click on the sourceforge link from his forum post to get the 
 apps):

 http://forum.dlang.org/thread/cdekkumjynhqoxvmgjze forum.dlang.org

 Let me know if you have any questions or problems.


Ok, so I installed
ldc2-android-arm-1.1.0-beta4-linux-x86_64.tar.xz

in to ldcandroid

and tried running

./bin/ldc2 -c test.d

I get the error.

./bin/ldc2: error while loading shared libraries: libconfig.so.9: 
cannot open shared object file: No such file or directory

Searched the file system for libconfig and found nothing so I did

sudo apt-get install libconfig++9

which installed it under lxss\rootfs\usr\lib\x86_64-linux-gnu

It shows up when I do

sudo ldconfig -v

/usr/lib/x86_64-linux-gnu:
libconfig++.so.9 -> libconfig++.so.9.1.3

I tried adding this:

export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu

But still same issue.

Any ideas how to fix this?
Dec 31 2016