| <<<Back 1 day (to 2016/12/27) | 20161228 |
sebras | Robin_Watts: have you successfully built the android app? | 16:40.31 |
Robin_Watts | sebras: Freds one? | 16:40.47 |
sebras | yea | 16:40.51 |
Robin_Watts | I think so, but not for a while. | 16:40.56 |
sebras | Robin_Watts: h. using android studio? | 16:41.08 |
Robin_Watts | Yes. | 16:41.13 |
sebras | Robin_Watts: for arm? or for x86? | 16:41.23 |
| hm.. armeabi-v7a. | 16:41.33 |
Robin_Watts | arm, I believe. | 16:41.34 |
sebras | I'm seeing runtime errors trying to call aeabi_memclr8, searching seems to indicate that it has to do with {min,target,compile}SdkVersion flags, but I'm not up to speed on what we have, what we want and what is recommended. | 16:42.45 |
| Robin_Watts: so the java compiles, but as soon as the native code is called the app crashess complaining that that memclr function cannot be found. | 16:43.18 |
| in the arm emulator that is. | 16:43.23 |
Robin_Watts | sebras: That is a symptom of too late an ndk being used, I think. | 16:43.42 |
| oops. being called away. | 16:44.26 |
sebras | Robin_Watts: as I understand android's approach you should always be able to compile using the latest NDK/SDK but target older versions if you so desire. | 16:44.27 |
| np. | 16:44.30 |
Robin_Watts | sebras: That's the theory, yes. | 16:48.48 |
| but something has gone wrong with our use of it. | 16:48.57 |
| If you can fix it, brilliant. | 16:49.04 |
| until now we've been working around it by using an older ndk. | 16:49.14 |
sebras | I'll do my worst. | 16:49.32 |
Robin_Watts | I have to say that I wouldn't be entirely averse to the idea of moving over entirely to Android Studio for doing the builds. | 16:52.24 |
| i.e. ditching ndk-build. | 16:52.32 |
sebras | they are not mutually exclusive, android studio can use cmake och ndk-build to build native code I believe. | 16:53.10 |
| but I need to create a working Android.mk for platform/java | 16:53.28 |
| step 1 however is to get _anything_ working. | 16:53.45 |
Robin_Watts | Android studio *can* use ndk-build to build NDK code, but is that its most natural way of working? | 16:53.54 |
sebras | I believe so. | 16:54.07 |
Robin_Watts | OK. | 16:54.15 |
sebras | but I _am_ pretty new to this. ;) | 16:54.20 |
Robin_Watts | I was thinking that maybe by constructing a 'normal' Android Studio build from scratch, you might end up with something working. | 16:54.43 |
| but if it requires ndk-build, then... boo. | 16:54.54 |
sebras | Robin_Watts: it is a humbling experience to leave the nitty gritty details of C and make and take a step up ontop of java and gradle and GUIs and notice how few things a battalion of engineers can coax into working out of the box. | 16:56.54 |
| not just us, the engineers making the tools too. | 16:57.13 |
Robin_Watts | sebras: Yeah. Their failure to produce decent tools speaks poorly of them. | 16:58.06 |
sebras | Robin_Watts: NDK revision history states for NDK r12: Removed all sysroots for platform levels prior to Android 2.3 (API level 9). We dropped support for them in NDK r11, but neglected to actually remove them. | 17:26.18 |
| and we require android-8, which the NDK then silently changes to android-24. | 17:26.39 |
Robin_Watts | Right. | 17:38.08 |
| So if we move to API level 9, all is solved? | 17:38.36 |
| My nook is 2.2, I believe, (and possibly, so was my first android phone) which is why I picked 2.2 to start with. | 17:39.31 |
| but moving past them is no hardship. | 17:39.44 |
sebras | no, level 9 didn't cut it. | 17:51.20 |
| don't know hy. | 17:51.32 |
| but chosing level 10 compiled something that I can run in an android 2.3.3 emulator. | 17:52.01 |
Robin_Watts | 9 is the first level that supports x86 and mips. | 17:52.31 |
sebras | yes, I read that in some .mk-file. | 17:53.01 |
| if I'm reading https://developer.android.com/about/dashboards/index.html#Platform correctly there 2.2 usage in 0.1%. sounds like we could decide to ignore those devices for the new app. | 17:54.18 |
Robin_Watts | sebras: Yes, IIRC everything prior to 4.4 is negligible. | 17:54.44 |
sebras | well, 15.3% are using 4.3 or older. | 17:55.28 |
| if you were to standardize on 4.0, then you'd only miss 1.3% of the devices. | 17:55.59 |
Robin_Watts | Well, I reckon move to API 10 for now and go higher if required. | 17:56.32 |
camelopard2 | Where is the gsview source repository? Is it released under (A)GPL? | 19:27.26 |
sebras | camelopard2: several of the devs are away for the holidays or may have stopped working for today. | 19:38.54 |
| camelopard2: so be prepared to wait for some time. | 19:39.01 |
| camelopard2: or return at a later time when there is more activity here. | 19:39.23 |
Robin_Watts | The gsview source repo is private I believe. | 19:39.45 |
sebras | Robin_Watts: both for older versions and current development versions? | 19:40.31 |
Robin_Watts | gsview 5 is nothing to do with us. | 19:40.49 |
| gsview 6 is ours, and is currently private. | 19:41.02 |
sebras | Robin_Watts: yey, I found a bug in clang 3.9.0 | 19:51.05 |
| Robin_Watts: apparently their integrated assembler fails to take the search paths into accound for incbin, where as the external assembler handles it perfectly fine. | 19:51.31 |
| Robin_Watts: so I can build mupdf for arm, but not for x86. | 19:57.17 |
| since arm disables the integrated assembler while x86 does not. | 19:57.44 |
camelopard2 | May I have comparefiles/jhalftone.pdf , please? My address is sphinx.pinastri@gmail.com . | 21:00.49 |
| Forward 1 day (to 2016/12/29)>>> | |