Android static linking

[Fizix]

I'm currently looking into building the android flavor of SFML as a static library and linking against them.  SFML has hard coded the fact that libraries are dynamic in the "glue" code, but i can't really find a place where this design choice and motivation is discussed, etc.

I've already started to poke at the code and came up with a few ideas, but if someone else also thought about this I would love to hear your comments.  Maybe we can come up with a more concrete plan to move forward with if possible.

[Mario]

I might remember this wrong, but the one big problem for static linking is the entry point, which won't be in your user code. It's sitting in sfml-activity.so. By using dynamic linking, it's just there and works. With static linking, it won't be included in your own library file unless referenced somewhere else (which isn't the case). As such you'd have to reimplement it yourself.

The problem is similar to sfml-main providing a WinMain entry point for compilation as a Win32 application (which by default won't use main), but it's easier to be handled properly (since there it is a link time dependency, which isn't the case for Android).

[Fizix]

Yes the entry point is stripped from the .so because it's not references, but there are ways around this.  There are compiler switches, which I don't know if it'll work on android toolchain.  The ndk sample glue code also has this problem and they use a dummy function to force the entry point to be referenced.

So it would just be a matter of finding the most elegant solution.

[Fizix]

Just an update to what I've found so far.  I was able to link statically with SFML on Android after I followed these steps.

I changed BUILD_SHARED_LIBS in the cmake file to be false (it is currently hard coded to true)
After building, there are -s variants of the libs in the ndk directory.  e.g. sfml-system-s.a, sfml-graphics-s.a
The Android.mk file already has -d flavor of libraries, so I added a -s option with all the libraries set to link statically.
I also changed the c++_shared option to c++_static.

The activity must also be changed not to use sfml-activity as the main native library any more, but just the example library.  The sfml-main module was set up so that it also has a NativeActivity entry point, which works out well.  This is also why it should be set as LOCAL_WHOLE_STATIC_LIBRARIES, so that the entry point doesn't get stripped.

I might have left out some steps, but this is the general idea to do it.

There is one big issue with this.  The sound libraries are still dynamic, so using the audio module will crash the app, because those libraries aren't loaded by the sfml-activity any more.  Linking them statically is possible, but there is an ongoing issue about that if I remember correctly.