Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

modified CMakeLists.txt for static linking of libcurl #1872

Merged
merged 2 commits into from Jul 30, 2019

Conversation

@jmjatlanta
Copy link
Contributor

commented Jul 26, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Jul 26, 2019

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.

Copy link
Member

left a comment

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

@abitmore abitmore added this to In development in Feature Release (3.3.0) via automation Jul 26, 2019
@abitmore abitmore added this to the 3.3.0 - Feature Release milestone Jul 26, 2019
@jmjatlanta

This comment has been minimized.

Copy link
Contributor Author

commented Jul 29, 2019

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

This comment has been minimized.

Copy link
Member

commented Jul 29, 2019

Looks better now. Thanks.

Copy link
Contributor

left a comment

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

@pmconrad pmconrad referenced this pull request Jul 30, 2019
@jmjatlanta jmjatlanta merged commit 9990f9f into develop Jul 30, 2019
3 checks passed
3 checks passed
ci/dockercloud Your tests passed in Docker Cloud
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
Feature Release (3.3.0) automation moved this from In development to Done Jul 30, 2019
@jmjatlanta jmjatlanta deleted the jmj_static_linux branch Jul 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
3 participants
You can’t perform that action at this time.