Closed abrca closed 7 years ago
STATIC flag including in CMakeLists.txt (with a few more set
to properly find the dependency librairies)
Using -DSTATIC=ON works partially. For uts-server - ok, but for civetweb it uses dynamic libs:
[ 41%] Performing configure step for 'civetweb' ... -- Found LibRt: /usr/lib64/librt.so -- Found OpenSSL: /usr/lib64/libssl.so;/usr/lib64/libcrypto.so (found version "1.0.1e")
I've done some modifications:
CIVETWEB_CUST_ARGS
to pass any additional options/args to the civetweb build.For example, to solve the dynamic librt.o:
cmake . -DBUNDLE_CIVETWEB=ON -DSTATIC=ON -DLINK_GCC_S=ON -DCIVETWEB_CUST_ARGS="-DLIBRT_LIBRARIES=/usr/lib/librt.a"
Using your example:
cmake . -DBUNDLE_CIVETWEB=ON -DSTATIC=ON -DCIVETWEB_CUST_ARGS="-DLIBRT_LIBRARIES=/usr/lib64/librt.a"
:
[ 41%] Performing configure step for 'civetweb'
...
-- Found LibRt: /usr/lib64/librt.a
-- Found OpenSSL: /usr/lib64/libssl.so;/usr/lib64/libcrypto.so (found version "1.0.1e")
-- Configuring done
-- Generating done
CMake Warning:
Manually-specified variables were not used by the project:
OPENSSL_USE_STATIC_LIBS
and it use shared libs.
If I use -DCIVETWEB_CUST_ARGS="-DLIBRT_LIBRARIES=/usr/lib64/librt.a -DOPENSSL_LIBRARIES=/usr/lib64/libssl.a;/usr/lib64/libcrypto.a"
, another error was:
[ 16%] Performing configure step for 'civetweb'
...
-- Found LibRt: /usr/lib64/librt.a -DOPENSSL_LIBRARIES=/usr/lib64/libssl.a
May be it's better to mandatory use the same ${OPENSSL_INCLUDE_DIR}, ${OPENSSL_LIBRARIES}, discovered by find_package, during civetweb makefile creation? There is no sense to build civetweb with one version of openssl and uts-server with another.
Alternatively, you can build the civetweb project separately. That way you will have complete access to the compilation options specific to your use case.
I've added the BUNDLE_CIVETWEB
option mostly for easily trying out uts-server. I would not consider it as a proper way to build a production ready binary. Having an external download in a build sequence is not the best idea ever, recovering the master branch is even worst.
I should have added a warning in the documentation...
Yes, may be it'll be better. At first glance, it seems that the -DBUNDLE_CIVETWEB=ON is "officially recommended" way. I already was going to ask you how to build this zoo separately ))
And BTW, what branch to use - civetweb/civetweb, or kakwa/civetweb?
I will put more clear notifications on the recommended way to install uts-server.
For the civetweb/civetweb kakwa/civetweb branch:
Hopefully, there will be a new release of civetweb soon, but it's entirely up to the civetweb maintainer, not me ^^.
The story behind it is that the OpenSSL 1.1.0 API support was added by a PR I submitted to civetweb/civetweb. But while the PR wasn't merged, I change the civetweb url to my fork in order to support OpenSSL >= 1.1.0 and it kind of stay that way even if the PR was merged a while ago.
For reference, the PR: https://github.com/civetweb/civetweb/pull/384
Commit https://github.com/kakwa/uts-server/commit/55dea707b9d7bb0207d884a9a4f7c91c5b0ba5f8 modify the doc to explicitly state BUNDLE_CIVETWEB=ON
as developpment/testing only, and not recommended for production
in order to make statically linked executable, add:
option(STATIC "static linked binary" OFF)
if (STATIC) SET(CMAKE_FIND_LIBRARY_SUFFIXES ".a") SET(BUILD_SHARED_LIBRARIES OFF) SET(CMAKE_EXE_LINKER_FLAGS "-static") endif (STATIC)
in CMakeLists.txt before first "find_package"