modified CMakeLists.txt for static linking of libcurl

[jmjatlanta]

Linking libcurl dynamically in Linux can be done with package manager distributions of curl (i.e. sudo apt-get install libcurl4-openssl-dev). Although such packages come with a static library included, using it causes linker failure. Linker errors seem to be releated to pthread, dl, and openssl.

Compiling libcurl from source fixes those linker issues. But evidently curl requires the libraries ssl and crypto to be after itself on the linker command line. Otherwise the linker will error due to undefined references. The current CMakeLists.txt files within BitShares do not have the ssl and crypto libraries after curl. This PR fixes that.

Additional notes:

The directive CURL_STATICLIB is already used for statically linking curl in Windows. I am reusing it in Linux to specify the library to link to and add the ssl and crypto libraries after curl.

Calling cmake without CURL_STATICLIB will (in all cases I have seen) default to using dynamic libraries, which do not seem to care about where the ssl and crypto libraries are on the linker command line.

Linking with curl dynamically results in a witness_node binary with the following output from ldd:

linux-vdso.so.1 (0x00007ffd4e4d6000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f77327d9000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f77325ba000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f77323b6000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f77321ae000)
libcurl.so.4 => /usr/local/lib/libcurl.so.4 (0x00007f7731f39000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f7731bb0000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7731812000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f77315fa000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7731209000)
/lib64/ld-linux-x86-64.so.2 (0x00007f77368de000)
libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f7730f7c000)
libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f7730ab1000)

Linking with curl statically results in a witness_node binary with the following output from ldd:

linux-vdso.so.1 (0x00007ffeab1ff000)
libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007ffa81482000)
libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007ffa80fb7000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ffa80d9a000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ffa80b7b000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007ffa80973000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ffa805d5000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffa801e4000)
/lib64/ld-linux-x86-64.so.2 (0x00007ffa85495000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ffa7ffe0000)

[jmjatlanta]

I would love to get rid of the extra ssl and crypto logic. If anyone has ideas on making sure they are after curl, I would appreciate the insight.

[abitmore]

Do we have to duplicate the same code in 3 files?

[jmjatlanta]

Do we have to duplicate the same code in 3 files?

Well, we could create a macro in the main CMakeLists.txt file and call it from the other 3. See 98bd37e

[abitmore]

Looks better now. Thanks.

[pmconrad]

Works. The key point is that you have to build libcurl.a yourself and not rely on the system-provided one, at least on Ubuntu bionic (tested with gitian builder).