Use installed module stem for .so soname
So that the SONAME will match the actual installed name. This allows two
shared libraries (with different LOCAL_MODULE names) to be built with
the same name, but in different locations. So to partially emulate
Soong's vendor_available, you could define:
include $(CLEAR_VARS)
LOCAL_MODULE := libmyutils
...
include $(BUILD_SHARED_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := libmyutils_vendor
LOCAL_VENDOR_MODULE := true
LOCAL_INSTALLED_MODULE_STEM := libmyutils.so
...
include $(BUILD_SHARED_LIBRARY)
All of the users would need to explicitly use libmyutils vs
libmyutils_vendor based on how their runtime lookup paths are going to
work, but it will install into both places:
/system/lib/libmyutils.so
/vendor/lib/libmyutils.so
Bug: 38225484
Test: Example similar to above, ensure DT_NEEDED / DT_SONAME are correct
Test: multiproduct_kati to verify the only module this changes on
master is libart_fake
Change-Id: Ifa4b8adff50d8b5a754c70ce8e865b05f9889c6c
diff --git a/core/dynamic_binary.mk b/core/dynamic_binary.mk
index 579338e..949793b 100644
--- a/core/dynamic_binary.mk
+++ b/core/dynamic_binary.mk
@@ -23,7 +23,7 @@
# The basename of this target must be the same as the final output
# binary name, because it's used to set the "soname" in the binary.
# The includer of this file will define a rule to build this target.
-linked_module := $(intermediates)/LINKED/$(my_built_module_stem)
+linked_module := $(intermediates)/LINKED/$(notdir $(my_installed_module_stem))
ALL_ORIGINAL_DYNAMIC_BINARIES += $(linked_module)
