static linking libssl and libcrypto

Aijaz Baig aijazbaig1 at
Tue Nov 5 17:22:37 UTC 2019

Thank you for the information.

I will address your points here:
1. I was not aware of the fact that only those symbols that have been used
get imported when linking a library statically. So that very well could be
the case. I didn't get what you mentioned about the static linking
preventing the program from requiring I mean the way I am
linking my library should be of no concern to the source code right? Or so
I think.

2. when I downloaded and compiled the openssl library (from source), I
followed the INSTALL read me. All it resulted was libssl.a and libcrypto.a.
I didn't find any file name So how will this static library
(archive) have references to on the system?? I am kind of
confused here now.

Keen to hear from you,


On Mon, Nov 4, 2019 at 4:59 PM Brice André <brice at> wrote:

> Hello,
> It's not an open-ssl issue, but more a compiler specific one.
> With info you provided, I cannot tell you what you get as results, but two
> points that may help:
>    1. regarding the 87 ssl symbols : when you link with a library, only
>    the useful symbols are imported. So, if the code in you libAPP library only
>    uses some sparse functions of libSSL, it's normal you only have
>    corresponding symbols in your final image. I don't know what you plan to
>    do, but note that statically linking your dll with open-ssl will prevent
>    this dll from needing the openssl dynamic library. But it will not prevent
>    your main program to require the open-ssl library to run properly if some
>    part of it is dynamically linked with open-ssl !
>    2. depending on how you compiled your libssl.a, it can be either a
>    static library containing the full openssl binary code, or a static library
>    that just makes the "link" between you code and the ssl dynamic library. In
>    the second case, even if you properly statically link with this lib, you
>    will still need the dll to execute your program.
> Regards,
> Brice
> Le lun. 4 nov. 2019 à 07:28, Aijaz Baig <aijazbaig1 at> a écrit :
>> I am trying to build a shared library that internally links openssl and
>> crypto libraries statically so I can use it in a production environment. To
>> that end I am using the following Makefile
>> APPBASE=/home/AB/Documents/APP/APP_2.17.0
>> OPENSSL1.0.2p_INSTALL_LOC=/home/AB/Documents/APP/OpenSSL-1.0.2p-installation
>> CC=gcc
>> CFLAGS= -Wall -g -O -fPIC
>> RM= rm -f
>> .PHONY: all clean
>> src=$(wildcard *Generic/*.c *Linux/*.c)
>> $(info source=$(src))
>> #we use the custom compiled openssl version
>> #and NOT the one available on the system
>> #INC=-I/usr/include/openssl
>> INC+=-I$(OPENSSL1.0.2p_INSTALL_LOC)/include/openssl
>> INC+=$(foreach d,$(incdir),-I$d)
>> $(info includes=$(INC))
>> #LIB=-llibssl -llibcrypto
>> LIB+=-lssl -lcrypto
>> $(info links=$(LIB))
>> #LIB+=-L/usr/lib/
>> obj=$(src:.c=.o)
>> all:
>> clean:
>>     $(RM) *.o *.so
>>     $(shell find $(APPBASE) -type f -iname "*.o" -exec rm -rf {} \;)
>> .c.o:
>>     ${CC} -static ${CFLAGS} $(INC) -c $< $(LIB) -o $@
>> $(obj)
>>     $(LINK.c) -shared $^ -o $@
>> As mentioned here (
>> I've changed the linker flags to:
>> -lcrypto -lz -ldl -static-libgcc
>> but it doesn't seem to change the size of the generated so file. On
>> checking for references to SSL in this so file, I see there are a total of
>> 87 entries
>> nm | grep -i "ssl" | wc -l
>> 87
>> whereas listing *only* the global symbols from libssl.a tells me it has
>> 1113 globally defined symbols.
>> nm -g ../OpenSSL-1.0.2p-installation/lib/libssl.a | grep -i "ssl" | wc -l
>> 1113
>> I do not know if libSSL got indeed linked statically or not. Could
>> someone please shed some light on it?
>> --
>> Best Regards,
>> Aijaz Baig


Best Regards,
Aijaz Baig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openssl-users mailing list