Closed William-Froelich closed 5 years ago
Does it actually even make sense to build a shared library for iOS? Not a rhetorical question, I don't know that much about iOS development. Our iOS CI build targets static library. The correct answer here may be we should disable even attempting to build a shared lib for this platform.
If shared libs do make sense, can you test the following patch?
diff --git a/src/build-data/cc/clang.txt b/src/build-data/cc/clang.txt
index 4b14d9c4b..2dc36dfe6 100644
--- a/src/build-data/cc/clang.txt
+++ b/src/build-data/cc/clang.txt
@@ -31,6 +31,7 @@ visibility_attribute '__attribute__((visibility("default")))'
<so_link_commands>
darwin -> "$(CXX) -dynamiclib -fPIC -install_name $(INSTALLED_LIB_DIR)/{soname_abi} -current_version {darwin_so_current_ver} -compatibility_version {darwin_so_compat_ver}"
+ios -> "$(CXX) -dynamiclib -fPIC -install_name $(INSTALLED_LIB_DIR)/{soname_abi} -current_version {darwin_so_current_ver} -compatibility_version {darwin_so_compat_ver}"
# The default works for GNU ld and several other Unix linkers
default -> "$(CXX) -shared -fPIC -Wl,-soname,{soname_abi}"
Things like this SO post
https://stackoverflow.com/questions/7187649/can-i-use-dynamic-libraryshared-object-in-my-iphone-app
make me think that actually shared library is not correct for IOS and we should just disable it.
I have disabled building shared libs on iOS since a) it never worked b) it is not clear it is desirable. If someone comes back and explains how and why shared lib on iOS would be useful, we can revisit (and ideally add some CI tests to prevent regressions).
I'm closing this since the build should now succeed. Feel free to reopen if you think this is the wrong resolution.
When building for ios using macOS Mojave 10.14.3, the generated Makefile uses -soname instead of -install_name. The workaround mentioned in https://github.com/randombit/botan/issues/861 is a temporary work-around.
Build output: build.log
Configure output