Static linking libssl.a and libcrypto.a on Linux x64 fails

[Aijaz Baig <aijazbaig1@xxxxxxxxx>]

So I posted this question over at stackoverflow (https://stackoverflow.com/questions/58771714/compiling-c-and-c-with-single-makefile) but the gist of it is as follows:

I am trying to statically link libssl.a and libcrypto.a into a static library of my own which I will be using in an application (Linux). So I first create that library (let's call it libAPP.a) and then I use that library in an application. So first things first:

1. when I checkout the contents of that library (nm libAPP.a | less) , almost all (I haven't confirmed every single one but it sure looks that way) SSL related symbols (ex. BIO_new) are left undefined in libAPP.a. Why is that?

2. perhaps this is related to question one above, but when I use libAPP.a in my application, I get a whole bunch of 'undefined reference to' errors for the SSL symbols; they disappear when I pass libSSL.a and libCrypto.a to the linker. may be I need a refresher course on libraries but what is the point of linking statically when I still have to keep those libraries?

3. Even after supplying all these libraries, my linker was complaining about a whole bunch of symbols like dlopen, dlclose etc so after some googling, I supplied -ldl and -lz to the linker. So those linker errors related to dlopen etc went but now it complains that it cannot find libz on the system when it is clearly present.

Can anyone please elaborate on the steps need for a clean static linking of libssl.a into an application? Is it even doable on Linux considering such tight coupling of libc everywhere?? If not what are the alternatives??

--

Best Regards,

Aijaz Baig