-
Enhancement
-
Resolution: Unresolved
-
P3
-
23
-
Cause Known
The handling of static libraries has been substandard for quite some time in the build. A better approach is needed.
I will introduce a new configuration option, --with-library-type=<dynamic|static|both>, and a corresponding LIBRARY_TYPE spec.gmk variable. The value of this variable will control what we do after compilation in NativeCompilation.gmk. If it is dynamic, we link it as we do now. If it is static, we will do a proper static library, making sure that hidden symbols in the .o files will be converted to local symbols in the resulting .a file. And if it is both, we'll do both.
Handling hidden symbols properly will allow us to get rid of ugly special handling for symbol collision.
Handling the library creation in NativeCompilation will allow us to get rid of ugly special targets.
I will introduce a new configuration option, --with-library-type=<dynamic|static|both>, and a corresponding LIBRARY_TYPE spec.gmk variable. The value of this variable will control what we do after compilation in NativeCompilation.gmk. If it is dynamic, we link it as we do now. If it is static, we will do a proper static library, making sure that hidden symbols in the .o files will be converted to local symbols in the resulting .a file. And if it is both, we'll do both.
Handling hidden symbols properly will allow us to get rid of ugly special handling for symbol collision.
Handling the library creation in NativeCompilation will allow us to get rid of ugly special targets.