search

kakwa / uts-server

Micro RFC 3161 Time-Stamp server written in C.
http://uts-server.readthedocs.org/en/latest/
MIT License
75 stars 21 forks source link

static linking #4

Closed abrca closed 7 years ago

abrca commented 7 years ago

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"

kakwa commented 7 years ago

STATIC flag including in CMakeLists.txt (with a few more set to properly find the dependency librairies)

abrca commented 7 years ago

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")

kakwa commented 7 years ago

I've done some modifications:

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"

abrca commented 7 years ago

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.

kakwa commented 7 years ago

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...

abrca commented 7 years ago

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 ))

abrca commented 7 years ago

And BTW, what branch to use - civetweb/civetweb, or kakwa/civetweb?

kakwa commented 7 years ago

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

kakwa commented 7 years ago

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