cellml
Cannot build a static version
If you set BUILD_SHARED to OFF then to build libCellML on Ubuntu 20.04 LTS will result in the following output:
$ ninja
[134/156] Linking CXX shared library tests/libtest_utils.so
FAILED: tests/libtest_utils.so
: && /usr/bin/c++ -fPIC -g -shared -Wl,-soname,libtest_utils.so -o tests/libtest_utils.so tests/CMakeFiles/test_utils.dir/test_utils.cpp.o src/libcellmld.a tests/gtest/libgtest.a /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/libxml2.so /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/libxml2.so src/libcellml_debug_utilities.a -lpthread && :
/usr/bin/ld: src/libcellmld.a(component.cpp.o): relocation R_X86_64_PC32 against symbol `_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EED1Ev' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
[136/156] Linking CXX executable tests/test_api_headers_validator
ninja: build stopped: subcommand failed.
On macOS:
ninja
[89/244] Linking CXX shared module src/bindings/python/libcellml/_version.so
FAILED: src/bindings/python/libcellml/_version.so
: && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -g -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk -bundle -Wl,-headerpad_max_install_names -o src/bindings/python/libcellml/_version.so src/bindings/python/CMakeFiles/version.dir/swig_intermediaries/versionPYTHON_wrap.cxx.o -Wl,-rpath,@loader_path/. src/libcellmld.a /usr/local/opt/[email protected]/Frameworks/Python.framework/Versions/3.9/lib/libpython3.9.dylib /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/lib/libz.tbd /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/lib/libxml2.tbd /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/lib/libz.tbd /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/lib/libxml2.tbd src/libcellml_debug_utilities.a && :
Undefined symbols for architecture x86_64:
"___llvm_profile_runtime", referenced from:
___llvm_profile_runtime_user in libcellmld.a(version.cpp.o)
(maybe you meant: ___llvm_profile_runtime_user)
"_llvm_gcda_emit_arcs", referenced from:
___llvm_gcov_writeout in libcellmld.a(version.cpp.o)
"_llvm_gcda_emit_function", referenced from:
___llvm_gcov_writeout in libcellmld.a(version.cpp.o)
"_llvm_gcda_end_file", referenced from:
___llvm_gcov_writeout in libcellmld.a(version.cpp.o)
"_llvm_gcda_start_file", referenced from:
___llvm_gcov_writeout in libcellmld.a(version.cpp.o)
"_llvm_gcda_summary_info", referenced from:
___llvm_gcov_writeout in libcellmld.a(version.cpp.o)
"_llvm_gcov_init", referenced from:
___llvm_gcov_init in libcellmld.a(version.cpp.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
[102/244] Swig compile ../interface/logger.i for python
ninja: build stopped: subcommand failed.
Looking at this I can't help but think that we should restrict what you build with a static libCellML library.
- Does it make sense to build coverage with a static library?
- Does it make sense to build the Python bindings with a static library?
Looking at this I can't help but think that we should restrict what you build with a static libCellML library.
- Does it make sense to build coverage with a static library?
I had a quick look and it seems like it might not be possible in fact, despite compiling it with the correct flags for gcov and llvm-cov. So, I would just prevent gcov and llvm-cov support when building a static library.
- Does it make sense to build the Python bindings with a static library?
Can't comment on that one. I use pybind11 for Python bindings in libOpenCOR, so it's done differently.
I have had a look at this and I think we might want to offer a configurable option for building a static library with or without position independent code. For some situations it is better and even required to build static libraries without position independent code and for others like building on 64bit Ubuntu you must build with it if you want to link it into something dynamic.
I am not sure whether we should worry about that. If someone wants a static version of libCellML for use in a shared library then it looks like they could pass -DCMAKE_POSITION_INDEPENDENT_CODE=ON or -DCMAKE_C_FLAGS=-fPIC to CMake (source: https://github.com/signalapp/libsignal-protocol-c/issues/50). So, if anything, I would document that rather than making it part of our CMake configuration process.