2

Been wondering and now confused.

When app_stl = stlport_static or stlport_shared is set in the Application.mk file and you are trying to build either shared and static version of the library. what is the effect,why would you have a specific case (see below) in your android ndk application ?

let say I have 

Case1: APP_STL=stlport_static and include $(BUILD_SHARED_LIBRARY) 
Case2: APP_STL=stlport_static and include $(BUILD_STATIC_LIBRARY) 

Case3: APP_STL=stlport_shared and include $(BUILD_SHARED_LIBRARY) 
Case4: APP_STL=stlport_shared and include $(BUILD_STATIC_LIBRARY)

I do understand the differnce between stlport and gnustl so I am good at that part.

Abhiram mishra
  • 1,597
  • 2
  • 14
  • 34

1 Answers1

2

Case1: APP_STL=stlport_static and include $(BUILD_SHARED_LIBRARY)
Case2: APP_STL=stlport_static and include $(BUILD_STATIC_LIBRARY)

These two configurations (static linking of STLport) could get you in trouble if you have two or more libraries that depend upon STLport. Because two or more libraries are carrying around symbols for STLport, you will likely violate the One Definition Rule.

I believe that's why doc/CPLUSPLUS-SUPPORT.html has:

II. Important Considerations
...

II.3. Static runtimes
...

Please keep in mind that the static library variant of a given C++ runtime SHALL ONLY BE LINKED INTO A SINGLE BINARY for optimal conditions.

What this means is that if your project consists of a single shared library, you can link against, e.g., stlport_static, and everything will work correctly.

On the other hand, if you have two shared libraries in your project (e.g. libfoo.so and libbar.so) which both link against the same static runtime, each one of them will include a copy of the runtime's code in its final binary image. This is problematic because certain global variables used/provided internally by the runtime are duplicated.

jww
  • 97,681
  • 90
  • 411
  • 885