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

[Aijaz Baig]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20191113/423d97d7/attachment.html>