On Wednesday, 1 April 2020 at 14:54:35 UTC, burt wrote:
> libphobos2-ldc.a and libphobos2-ldc-debug.a. Sizes are 2511 kB, 4792 kB, 10.010 kB and 17.378 kB respectively.

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

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

On Wednesday, 1 April 2020 at 15:01:02 UTC, Adam D. Ruppe wrote:
> On Wednesday, 1 April 2020 at 14:54:35 UTC, burt wrote:
>> libphobos2-ldc.a and libphobos2-ldc-debug.a. Sizes are 2511 kB, 4792 kB, 10.010 kB and 17.378 kB respectively.
>
> Those latter two should be megabytes not kilobytes.... the download must have failed.

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

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

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

On Wednesday, 1 April 2020 at 15:04:02 UTC, burt wrote:
> Well I'm European, so with 10.010 kB I mean 10010 kB = 10.010 MB in American/British.

ah, of course.

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

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

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

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

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

On Thursday, 2 April 2020 at 01:53:30 UTC, Adam D. Ruppe wrote:
> On Wednesday, 1 April 2020 at 15:04:02 UTC, burt wrote:
>> Well I'm European, so with 10.010 kB I mean 10010 kB = 10.010 MB in American/British.
>
> ah, of course.
>
>> Well, I won't be able to finish it today anyway, so take your time.
>
> I rewrote the downloader so it goes straight from ldc releases instead of depending on me, so this should give a lot more compatibility. Also made `dub run d_android:setup` a thing (though dub sometimes will try to run what it already has and it needs the new version for this, so you might need to fetch new version first). And fixed a bit in readme and other bugs...
>
> I only did rudimentary testing though... compiled my test on linux with no error so I think it is good. I'll be on my Windows computer tomorrow and be able to run more tests there.
>
> But if you get to it before me, it *might* work now. You may have to edit your ldc2.conf file and delete the old generated addons to give it a cleaner slate too.
>
> otherwise, I'll email again once I get a chance to test it more in the morning. (I'm in US Eastern so you are several hours ahead of me in Europe!)

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

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

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

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

On Thursday, 2 April 2020 at 12:13:27 UTC, Adam D. Ruppe wrote:
> On Thursday, 2 April 2020 at 11:29:24 UTC, burt wrote:
>> Anyway, I don't think this fails to work because of an error in the d_android library. If you find anything else that may cause it, I am glad to know, but thank you for your help.
>
> Well, it is supposed to be a "just works" setup helper, so anything in it is a problem! There was an off-by-one bug in the downloader, maybe that missing byte made ldc ignore the corrupted library file.

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

On Thursday, 2 April 2020 at 17:16:56 UTC, burt wrote:
> On Thursday, 2 April 2020 at 12:13:27 UTC, Adam D. Ruppe wrote:
>> On Thursday, 2 April 2020 at 11:29:24 UTC, burt wrote:
>>> Anyway, I don't think this fails to work because of an error in the d_android library. If you find anything else that may cause it, I am glad to know, but thank you for your help.
>>
>> Well, it is supposed to be a "just works" setup helper, so anything in it is a problem! There was an off-by-one bug in the downloader, maybe that missing byte made ldc ignore the corrupted library file.
>
> I think I managed to get phobos2 and druntime to link. However, I still get linker errors saying that the following symbols are undefined: statvfs, fmodl, modfl, getdelim, _tlsend, __bss_end__, _tlsstart, __libc_current_sigrtmin, __libc_current_sigrtmax, strtold. I'm not sure what to do about that; did I forget to link something or are these symbols not in the Android runtime?

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

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

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

Thanks.

Little off-topic, but I think it should fit here well.

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

On the weekend I started creating an App (kotlin), really simple stuff.
However there is just so much to know.
It is really overwhelming.

On Thursday, 2 April 2020 at 12:13:27 UTC, Adam D. Ruppe wrote:
> On Thursday, 2 April 2020 at 11:29:24 UTC, burt wrote:
>> Anyway, I don't think this fails to work because of an error in the d_android library. If you find anything else that may cause it, I am glad to know, but thank you for your help.
>
> Well, it is supposed to be a "just works" setup helper, so anything in it is a problem! There was an off-by-one bug in the downloader, maybe that missing byte made ldc ignore the corrupted library file.

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

```
import arsd.jni;

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

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

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

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

Thanks.

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

On Tuesday, 7 April 2020 at 11:45:24 UTC, burt wrote:
> I managed to get it to compile. I had to add __bss_end__ symbol myself and set the value to the value of the `_end` symbol or it wouldn't work. A PR to the LDC druntime is wat caused the __bss_end__ symbol to be missing [0].

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


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

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

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

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


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