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 libSSL.so. 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 libSSL.so. So how will this static library
(archive) have references to libSSL.so on the system?? I am kind of
confused here now.
Keen to hear from you,
Aijaz
On Mon, Nov 4, 2019 at 4:59 PM Brice André <br...@famille-andre.be> 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 <aijazba...@gmail.com> 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=-L$(OPENSSL1.0.2p_INSTALL_LOC)/lib
>> #LIB=-llibssl -llibcrypto
>> LIB+=-lssl -lcrypto
>> $(info links=$(LIB))
>> #LIB+=-L/usr/lib/
>>
>> obj=$(src:.c=.o)
>> all: libAPP.so
>> clean:
>> $(RM) *.o *.so
>> $(shell find $(APPBASE) -type f -iname "*.o" -exec rm -rf {} \;)
>>
>> .c.o:
>> ${CC} -static ${CFLAGS} $(INC) -c $< $(LIB) -o $@
>>
>> libAPP.so: $(obj)
>> $(LINK.c) -shared $^ -o $@
>>
>> As mentioned here (
>> https://stackoverflow.com/questions/18185618/how-to-use-static-linking-with-openssl-in-c-c/25811538#25811538),
>> 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 libAPP.so | 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
