Building for Android doesn't generate shared lib (.so)

[scorpeeon]

I made a standalone NDK toolchain with Fortran support using the latest NDK (r14b) following these instructions:
https://github.com/buffer51/android-gfortran

Using latest develop branch of OpenBLAS, followed this guide to build OpenBLAS with Fortran:
https://github.com/xianyi/OpenBLAS/wiki/How-to-build-OpenBLAS-for-Android

The build itself seemingly goes fine (without error) but the install command says it can't find the .so file - I checked, and it's not generated for some reason (can't find any .so files within the folders). So the install command only generates the header files and the static (.a) lib, but not the shared (.so) lib. Tried both arm and arm64, happens in both versions.

The relevant error message (when running the install command) :

Copying the shared library to /home/scrpn/blas/OpenBLAS/install/lib
install: cannot stat 'libopenblas_armv7p-r0.2.20.dev.so': No such file or directory
make[1]: *** [install] Error 1

Also attached build log.
log.txt

Any ideas what's wrong?

[martin-frbg]

Build log looks a bit short, is that from the complete build (after "make clean") or continuing after an earlier interruption ?
See if you set NO_SHARED=1 somewhere, otherwise the shared library should be built by the toplevel Makefile (which should be running make -C exports so and adding a few softlinks afterwards)

[scorpeeon]

@martin-frbg Yeah you're right, it's probably not the full log, it's the log after a build was already done (or at least attempted). The original log was too long to copy out of the console as I couldn't scroll back to the beginning - is the build log saved somewhere or should I just increase the scrollback size of the terminal?

I only ran the commands from the guides I referenced and I don't thinks there's a NO_SHARED=1 in any of those. Gonna try to get a full log tomorrow.

[martin-frbg]

The build log is not saved, what you could do is redirect the console output to a file.
Looking at the wiki recipe it could be that the problem comes simply from building only the "libs" target, try repeating that command line with "shared" instead of "libs" at the end.

[brada4]

You can collect output by typing 'script'
Pobably add -s parameter to make at first attempt to shorten the output to read
Once done with demonstrating error, exit script wrapper (Ctrl-D/exit/whatever) and examine file 'typescript' for your output.

[scorpeeon]

Thanks for the tips.
I successfully grabbed a full log, attached it.

log.txt

Meanwhile I also tried the "shared" option instead of "libs" as suggested by @martin-frbg, first it gave an error saying I first need static libs to do that. I suppose one could use both the libs and shared options to get both (or just run it with first the libs. then the shared option?), but while at it, I tried the "all" option to see what happens and it actually ran all the way through with no errors and I could also successfully run the install command and saw the shared lib files were generated.
Actually 3 shared lib files have been generated: libopenblas.so, libopenblas.so.0, libopenblas_armv7p-r0.2.20.dev.so - I'm not sure why - I think all 3 are binary equal).

Just to have it in case it's needed I also included to full log for building with the "all" option:
log_all.txt

So it looks like @martin-frbg was on point, it was just because of the options that the .so didn't got generated.

I haven't actually tested it yet though and the Android guide says:
"Since we are cross-compiling, we make the libs recipe, not all. Otherwise you will get errors when trying to link/run tests."

So I probably shouldn't use the all option after all. I checked in the Makefile and it looks like the all option means these: libs netlib tests shared
We know we need libs and shared (well, technically one of them could be enough, but I'm not sure yet if we'd use at as a shared or static lib so it's handy to have both), and according to the Android guide we shouldn't include tests. What is netlib, do we need that? After a quick search I found it probably refers to Netlib Lapack, but I'm still unsure what this option exactly does. Does it mean it includes the full Lapack lib if this option is set?

[martin-frbg]

Yeah, my suggestion was assuming that you had already run make ... libs before. It could be that the wiki entry is from a time where the build system did not yet detect cross-compilation, or did not know to avoid running the tests in the cross-compilation case. (Obviously it would not make sense to try to run the newly built Android code on the desktop computer used for compilation).
The 3 shared lib files are indeed equal - actually I think you will find that only the one with the longest name is an actual file, while the other two are symbolic links to it so that one can refer to it as just "openblas" for linking or when running code linked against it.
Finally as you assumed the make ... netlib would build the lapack part (but only if you have the gfortran compiler installed, as LAPACK is written in FORTRAN). So in effect running make all should not hurt.

[scorpeeon]

@martin-frbg Thanks for the quick reply.

Indeed it looks like the multiple files are symbolic links to the same file (Ubuntu file manager didn't display this for some reason).

Yeah, so one of my goals would be to also include Lapack, so I'm using a custom standalone Android NDK toolchain (referenced in my first post) with Fortran support, so compiling Fortran (and Lapack) shouldn't be an issue.

One thing I don't quite get (sorry, I'm pretty new at this) yet is how can I combine these options (libs, shared, netlib). Can i just call it with multiple options like make ... libs netlib shared?
Or first I would have to call "libs", then "shared" - and also "netlib" at some point? This is confusing to me because even when I ran the "all" option, in the install folder I found no separate file/lib for Lapack - I suspect it is included in the same libopenblas static/shared files, right? But in this case what happens if I just run make ... netlib without either "libs" or "shared" options, where is Lapack then placed? (I guess it doesn't make sense to only run it with "netlib" option, only if you later also call it with "libs" or "shared"?)

I found that if I call it with options make ... libs shared, I get several errors like these:

/tmp/ccjsikY2.o:linktest.c:function main: error: undefined reference to 'spotri_'
/tmp/ccjsikY2.o:linktest.c:function main: error: undefined reference to 'dpotri_'
/tmp/ccjsikY2.o:linktest.c:function main: error: undefined reference to 'cpotri_'
[...]
/tmp/ccjsikY2.o:linktest.c:function main: error: undefined reference to 'LAPACKE_cgb_nancheck'
/tmp/ccjsikY2.o:linktest.c:function main: error: undefined reference to 'LAPACKE_cgb_trans'
[...]

So it looks like the shared libs needs netlib/lapack.
But if I run it with make ... libs netlib shared it seemingly compiles fine - so it's probably my best option, right?

Or you think I can just use the "all" option (which also includes tests) and ignore the warning regarding the link/run errors in the guide? (of course I probably wouldn't want to run tests on Android, I would just use the library)

[martin-frbg]

Yes, just use the "all" option. The LAPACK functions will be included in the library.

[scorpeeon]

@martin-frbg great, thanks! Now I'm trying to use the shared library in an Android project. The problem is that the generated shared lib (libopenblas_armv8p-r0.2.20.dev.so) has a versioned SONAME:
0x000000000000000e (SONAME) Library soname: [libopenblas.so.0]

(see: the .0 after the .so part). Android doesn't support versioned SONAMEs, so there shouldn't be anything after the ".so" part.

Is there any easy way to modify the build process so that the SONAME entry would be libopenblas.so?

[martin-frbg]

Try removing the first occurence of .$(MAJOR_VERSION) in exports/Makefile - if this turns out to be the right spot we can try to put some form of "if android" around it.

[scorpeeon]

@martin-frbg Thanks, that indeed looks like it's working!
First I found a part similar to that in the Makefile of the root directory where Android is handled the same way as Linux and SunOS, but that part looks like it's only creating the symbolic links. In this case it's creating two links one of them being $(LIBSONAME) $(LIBPREFIX).so.$(MAJOR_VERSION) - which doesn't make much sense on Android but having an additional unused symbolic link is no real issue.

Meanwhile I also got the Android app to work by using the static lib instead of the shared one. Using a static lib allows Android build to strip away unused code, so maybe it can be even preferable to using a shared lib, especially since the full shared lib size is at around 10 MB (the full static lib would be 20 MB, but I think most of the time only a small portion of that is needed)

[martin-frbg]

Looking at the commit log, shared library support for Android was added only a few weeks ago (by xianyi on Apr 11 ), keeping the soname versioning was probably just an oversight there. I'll submit a fix over the weekend if nobody beats me to it.

[scorpeeon]

Yeah OK, great!

I also tested the shared library in the Android app, but apparently I get a crash on startup when loading the lib because of some missing symbol:

java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "_gfortran_compare_string" referenced by "/data/app/com.my.package-1/lib/arm64/libopenblas.so"...

Not sure why it's missing from shared while it's OK with static.

[martin-frbg]

Do you have a libgfortran.so on the Android ? You may have to modify the linker flags so that the shared openblas gets built with its dependencies all linked statically (at which point there may be even less point in having a share libopenblas, except perhaps to be able to replace it as needed).

[brada4]

Where is that build log? It is apparent that your cross-compiler does not find (or have) target fortran library and cannot link resulting object. It whould be above linktest, something like gcc/gfortran/ld *.o -o libopenblas.so
What functions you intend to use from OpenBLAS? e.g if no lapack is needed dont build it...