static linking about uts-server

[kakwa]

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

[abrca]

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]

I've done some modifications:

• forwarding the OPENSSL_USE_STATIC_LIBS flag in civetweb external project.
• adding a 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"

[abrca]

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]

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]

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]

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

[kakwa]

I will put more clear notifications on the recommended way to install uts-server.

For the civetweb/civetweb kakwa/civetweb branch:

• If you are using OpenSSL < 1.1.0 use lastest tag of civetweb/civetweb
• If you are using OpenSSL >= 1.1.0 use the master branch of civetweb/civetweb. At least for now, the current release (1.9.1) doesn't include the OpenSSL 1.1.0 API support.

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: civetweb/civetweb#384

[kakwa]

Commit 55dea70 modify the doc to explicitly state BUNDLE_CIVETWEB=ON as developpment/testing only, and not recommended for production