Recompile with -fPIC on Android x86

[Zombieschannel]

Subject of the issue

When using SFML 2.6.x branch and compiling SFML for Android, Android Studio throws out an error saying to recompile x86 architecture with -fPIC. Adding this into the CMAKE_CXX_FLAGS and CMAKE_C_FLAGS in CMakeCache is a temporary fix.

Your environment

Android Studio 2022.1.1 on Windows 10
SFML 2.6.x branch
Used CMake, Ninja, Android NDK 25

Steps to reproduce

I followed this tutorial that was mentioned on the Github Wiki:
https://github.com/SFML/SFML/wiki/Tutorial:-Building-SFML-for-Android-on-Windows-with-Android-Studio

Expected behavior

It should compile for x86 (it works for arm, arm64 and x86_64)

Actual behavior

An error is thrown:

ld: error: relocation R_386_PC32 cannot be used against symbol 'sf::NonCopyable::NonCopyable()'; recompile with -fPIC
  >>> defined in C:/Users/cutel/AppData/Local/Android/Sdk/ndk/25.1.8937393/sources/third_party/sfml/lib/x86/libsfml-main-d.a(MainAndroid.cpp.o)
  >>> referenced by Thread.inl:77 (C:/Users/cutel/SFML-2.6.x-Android/SFML-2.6.x/include/SFML/System/Thread.inl:77)
  >>>               MainAndroid.cpp.o:(sf::Thread::Thread<void* (*)(sf::priv::ActivityStates*), sf::priv::ActivityStates*>(void* (*)(sf::priv::ActivityStates*), sf::priv::ActivityStates*)) in archive C:/Users/cutel/AppData/Local/Android/Sdk/ndk/25.1.8937393/sources/third_party/sfml/lib/x86/libsfml-main-d.a

[ChrisThrasher]

Can you fix this by building SFML as shared libraries? CMake automatically adds that flag to all shared libraries.

[Zombieschannel]

Not sure what you mean by "building SFML as shared libraries". All of the SFML modules + OpenAL are along side the main libapp.so in the final apk (libsfml-graphics.so, libsfml-system.so, libsfml-window.so, libopenal.so, libsfml-audio.so, libsfml-network.so)
If you mean the -DCMAKE_ANDROID_STL_TYPE=c++_static flag, it asks for recompilation with -fPIC either way.

[ChrisThrasher]

Looks like you're already building shared libraries. If all libraries are shared then -fPIC is already applied to everything. Then the question becomes where are there static libraries causing this problem?

[Zombieschannel]

I'm not sure how to build SFML as static libraries on Android. I don't know what that -fPIC does to the .so files but it does fix the issue and it isn't in CMakeCache by default. Also might be an Android Studio issue?

[ChrisThrasher]

I'm not sure how to build SFML as static libraries on Android

I'm not asking you to build static libraries.

I don't know what that -fPIC does to the .so files

That flag should already get applied when building those .so files which is why I'm confused you need to add this. Cmake already solves this problem for us.

[Zombieschannel]

I'm not asking you to build static libraries.

I know but I've heard that it isn't implemented yet/is difficult to get it to work that way (at least in SFML's current state).

That flag should already get applied when building those .so files which is why I'm confused you need to add this. Cmake already solves this problem for us.

How recently has that been added? Maybe my 2.6.x download is already outdated?

[ChrisThrasher]

How recently has that been added?

I think it dates back to CMake 3.0 if not earlier so I'd expect SFML 2.6 with its relatively old CMake requirement to still do it.

[kimci86]

Then the question becomes where are there static libraries causing this problem?

The error message mentions libsfml-main-d.a.

[ChrisThrasher]

The error message mentions libsfml-main-d.a.

Ah, we always build sfml-main as a static library. I wonder why that is.

https://github.com/SFML/SFML/blob/2.6.x/src/SFML/Main/CMakeLists.txt#L17

[ChrisThrasher]

Allowing sfml-main to be built as a shared library is throwing up plenty of linker errors. This may be fixable but either way, I think we can easily set the POSITION_INDEPENDENT_CODE target property to ON so that we build this with -fPIC. I know this flag is not technically zero cost but I figure it's worth enabling for the sake of it actually being usable.

EDIT: ChrisThrasher@3ad75f2

[eXpl0it3r]

Ah, we always build sfml-main as a static library. I wonder why that is.

I'm not 100% sure about Android, but since sfml-main also defines the main entry point, it can't reside in some shared library, at least to my knowledge, you can't run an executable which has an entry point in a shared library.