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.

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?

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.

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

root@DESKTOP:/mnt/b/DLang/ldc2Android# bin/ldmd2 test.d
bin/ldmd2: error while loading shared libraries: libncursesw.so.6: cannot open shared object file: No such file or directory
root@DESKTOP:/mnt/b/DLang/ldc2Android# bin/ldmd2 test.d
bin/ldmd2: error while loading shared libraries: libncursesw.so.6: cannot open shared object file: No such file or directory
root@DESKTOP:/mnt/b/DLang/ldc2Android# bin/ldmd2 test.d
bin/ldmd2: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by bin/ldmd2)
root@DESKTOP:/mnt/b/DLang/ldc2Android# bin/ldc2 test.d
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

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.

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.



root@:/mnt/b/DLang/ldc2Android# gcc -v
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?

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

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.

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.

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.