I am trying to include a locally built (built as a part) OpenSSL (v 1.1.0f) in a websocket (again a part). But I get below errors while building websocket part (in a snapcraft.yaml).
cmake: /home/vbidkar/wsclient/os-ws-client/stage/usr/lib/libssl.so.1.1: version `OPENSSL_1_1_1’ not found (required by /usr/lib/x86_64-linux-gnu/libcurl.so.4)
Could someone through light on what this error is about?
Before building OpenSSL as a part I was making use of openssl form /usr/lib/ (native lib of VM) and it worked fine.
From the look of it, the cmake build tool is trying to link against your locally built libssl, and this fails because it is older than the version shipped in Ubuntu 18.04 (OpenSSL 1.1.1).
During the build process, Snapcraft adds various directories under $SNAPCRAFT_STAGE to $LD_LIBRARY_PATH this is so you can have one part build a tool that a subsequent part can use that tool. Unfortunately this also means that operating system provided tools may end up using staged libraries, which causes the problem you’ve seen.
I think there are two main questions to ask yourself:
do you really need to ship your own copy of OpenSSL? By using the version from the base snap, you’ll automatically pick up any security fixes for the library that get rolled out to the base snap you’re using.
if you do need to ship your own OpenSSL, does it really need to be a version older than that provided by your base?
You got it right @jamesh. The version that I am building as a part is OpenSSL 1.1.0f. Let’s assume (for reasons beyond my control) this is the version that I have to use. So answer to #1 and #2 is YES.
Having said that, is there a way to force cmake / libcrul make use of the OpenSSL version that is built as a part through snapcraft.yaml file?
I’m not sure there is a full solution to this problem. There are a few work arounds that might help though:
Use the after: clause on the part building OpenSSL to have it run after the part that builds using cmake. This should work if you only need the custom OpenSSL at runtime rather than build time for that part. This could still
Use the older core snap as a base rather than core18. You’d no longer be downgrading to an OpenSSL that lacks symbols found in the version found in the base. The main downside of this is that the core snap will drop out of support 2 years before core18. That might not be a problem if you seem to be stuck on old library versions though.
I still think the best option would be to not ship a custom version of OpenSSL, but that seems to be off the table for you.
