On 20 June 2017 at 03:57, Lubomir I. Ivanov <[email protected]> wrote:
> On 19 June 2017 at 13:31, Rick Walsh <[email protected]> wrote: > > > --sysroot=/home/rick/src/subsurface/ndk-arm/sysroot > > go to that folder and investigate and grep / nm for "rand" in both > the lib and include (if there are such under "usr"). > > lib $ grep rand * -rn > ... > Binary file libc.a matches > Binary file libc.so matches > > nm libc.a | grep rand > ... > > lrand48.o: > 00000001 T lrand48 <--- in my case this is the one of interest (see note > bellow) > > > -lusb-1.0 -lxml2 -lsqlite3 -lxslt -lxml2 -lz -lm -lxml2 -lzip -lz > -lusb-1.0 > > SIDENOTE: these appear to be added multiple times in the same linker > command line. not a great thing to have. > > > /home/rick/src/subsurface/libgit2-0.24.1/src/cache.c:117: error: > undefined > > reference to 'rand' > > i've just checked my toolchain and it appears that rand() is inline > defined as: > > static __inline__ int rand(void) { > return (int)lrand48(); > } > > go to the sysroot and see if that's the case for you in include/stdlib.h. > > if that's the case the real symbol it should be looking for is lrand48 > and not rand. > for me libc itself does not contain a "rand" symbol exactly, but the > *rand48 family. > > so the above message makes no sense, unless libgit's cache.c is built > with a toolchain that doesn't have the above inline rand(). > Yes, rand() is defined inline similarly on my system too in subsurface/ndk-arm/sysroot/usr/include/stdlib.h > > try clearing everything up and observe with verbose mode when libgit > is being built. > build.sh line 258 ---> add VERBOSE=1 > > [ 8%] Building C object CMakeFiles/git2.dir/src/cache.c.o /home/rick/src/subsurface/../android-ndk-r13b/toolchains/ arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc --sysroot=/home/rick/src/subsurface/../android-ndk- r13b/platforms/android-24/arch-arm -DGIT_ARCH_32 -DGIT_OPENSSL -DGIT_THREADS -D_FILE_OFFSET_BITS=64 -I/home/rick/src/subsurface/libgit2-0.24.1/src -I/home/rick/src/subsurface/libgit2-0.24.1/include -I/home/rick/src/subsurface/libgit2-0.24.1/deps/http-parser -isystem /home/rick/src/subsurface/../android-ndk-r13b/platforms/ android-24/arch-arm/usr/include -I/home/rick/src/subsurface/ ndk-arm/sysroot/usr/include/openssl -D_GNU_SOURCE -Wall -Wextra --sysroot=/home/rick/src/subsurface/ndk-arm/sysroot -march=armv5te -mthumb -msoft-float -mtune=xscale -funwind-tables -no-canonical-prefixes -fexceptions -Wno-missing-field-initializers -Wstrict-aliasing=2 -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-function -g -fPIC -o CMakeFiles/git2.dir/src/cache.c.o -c /home/rick/src/subsurface/ libgit2-0.24.1/src/cache.c libgit builds ok (including cache.c), and the verbose option shows that it is building for Android platform api 24, whereas subsurface-mobile was being built with api 16. I'm sure there's some way to force libgit to build with api 16 (maybe removing all later platforms from android-ndk-r13b/platforms), but I went the other way, and changed --api=16 to --api=24 in line 124 of build.sh. I can now build all the subsurface-mobile code. The Android packaging stumbled with an error about gradle, openjdk and cacerts. I "solved" it by downgrading openjdk from version 1:1.8.0.131-1.b12.fc25.x86_64 to 1:1.8.0.111-1.b16.fc25.x86_64 after reading this bug report https://github.com/gradle/gradle/issues/1782 Gradle(?) is now stuck at: Checking the license for package Android SDK Platform 24 in /home/rick/src/subsurface/../android-sdk-linux/licenses License for package Android SDK Platform 24 accepted. Preparing "Install Android SDK Platform 24". I think it might be hanging due to the insanely slow and unreliable internet connection where I'm staying at the moment. On 20 June 2017 at 05:59, Anton Lundin <[email protected]> wrote: The gcc toolchain we're using in the ndk is about to be deprecated, so we should focus on trying to switch over to clang. In NDK 15 GCC is no longer supported: https://developer.android.com/ndk/downloads/revision_history.html That sounds like a substantial change and I wish I could offer some help. I'm not sure the problem with my setup is due to the gcc toolchain so much as the ndk configuration. Cheers, Rick
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
