static linking libssl and libcrypto

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

static linking libssl and libcrypto

Aijaz Baig
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 $@
-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
Reply | Threaded
Open this post in threaded view
|

Re: static linking libssl and libcrypto

Brice André-2
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 <[hidden email]> 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 $@
-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
Reply | Threaded
Open this post in threaded view
|

RE: static linking libssl and libcrypto

Floodeenjr, Thomas
In reply to this post by Aijaz Baig

To check if you are linked statically or dynamically, what does ldd tell you? (ldd libAPP.so) Your library should not have a dependency on libssl.so or libcrypto.so if you are linked statically.

 

-Tom

 

From: openssl-users [mailto:[hidden email]] On Behalf Of Aijaz Baig
Sent: Sunday, November 3, 2019 11:30 PM
To: [hidden email]
Subject: static linking libssl and libcrypto

 

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 $@

-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

Reply | Threaded
Open this post in threaded view
|

Re: static linking libssl and libcrypto

Aijaz Baig
In reply to this post by Brice André-2
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é <[hidden email]> 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 <[hidden email]> 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 $@
-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
Reply | Threaded
Open this post in threaded view
|

Re: static linking libssl and libcrypto

Aijaz Baig
In reply to this post by Floodeenjr, Thomas
ldd libAPP.so does NOT have any reference to libSSL.so or for that matter any SSL library. Which is why I had to use nm to check for SSL related symbols

On Mon, Nov 4, 2019 at 6:31 PM Floodeenjr, Thomas <[hidden email]> wrote:

To check if you are linked statically or dynamically, what does ldd tell you? (ldd libAPP.so) Your library should not have a dependency on libssl.so or libcrypto.so if you are linked statically.

 

-Tom

 

From: openssl-users [mailto:[hidden email]] On Behalf Of Aijaz Baig
Sent: Sunday, November 3, 2019 11:30 PM
To: [hidden email]
Subject: static linking libssl and libcrypto

 

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 $@

-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
Reply | Threaded
Open this post in threaded view
|

Re: static linking libssl and libcrypto

Brice André-2
Then it means you properly compiled SSL in static.

Regarding my first point, what I mean is that : if you statically link your libApp.so with ssl library, it will no need any dynamic library dependencies, which is probably what you want. But your libApp.so will be loaded by a program. If this program also uses SSL (direct access, not through your libApp.so library), and performs a dynamic link, you will still need the ssl.so to run your application, even if your dll is statically linked with it.

Regards,
Brice


Le mar. 5 nov. 2019 à 18:24, Aijaz Baig <[hidden email]> a écrit :
ldd libAPP.so does NOT have any reference to libSSL.so or for that matter any SSL library. Which is why I had to use nm to check for SSL related symbols

On Mon, Nov 4, 2019 at 6:31 PM Floodeenjr, Thomas <[hidden email]> wrote:

To check if you are linked statically or dynamically, what does ldd tell you? (ldd libAPP.so) Your library should not have a dependency on libssl.so or libcrypto.so if you are linked statically.

 

-Tom

 

From: openssl-users [mailto:[hidden email]] On Behalf Of Aijaz Baig
Sent: Sunday, November 3, 2019 11:30 PM
To: [hidden email]
Subject: static linking libssl and libcrypto

 

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 $@

-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
Reply | Threaded
Open this post in threaded view
|

Re: static linking libssl and libcrypto

OpenSSL - User mailing list
In reply to this post by Aijaz Baig
Regarding #1: Using libSSL.a instead of libSSL.so should avoid using
libSSL.so by definition.  Otherwise something went seriously wrong
with the linking.  Same for any other library.

On 05/11/2019 18:22, Aijaz Baig wrote:

> 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.
>
>
> On Mon, Nov 4, 2019 at 4:59 PM Brice André <[hidden email]
> <mailto:[hidden email]>> 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.
>
>

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Reply | Threaded
Open this post in threaded view
|

Re: static linking libssl and libcrypto

Brice André-2
Sorry, but you are wrong : using libSSL.a in your libApp.so library does not prevent you from using libSSL.so elsewhere in your program. In such case, your program would still need libSSL.so

Le mer. 6 nov. 2019 à 09:38, Jakob Bohm via openssl-users <[hidden email]> a écrit :
Regarding #1: Using libSSL.a instead of libSSL.so should avoid using
libSSL.so by definition.  Otherwise something went seriously wrong
with the linking.  Same for any other library.

On 05/11/2019 18:22, Aijaz Baig wrote:
> 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.
>
>
> On Mon, Nov 4, 2019 at 4:59 PM Brice André <[hidden email]
> <mailto:[hidden email]>> 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.
>
>

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Reply | Threaded
Open this post in threaded view
|

Re: static linking libssl and libcrypto

Aijaz Baig
In reply to this post by Brice André-2
Ok. Got it. Thanks

On Wed, Nov 6, 2019 at 1:41 PM Brice André <[hidden email]> wrote:
Then it means you properly compiled SSL in static.

Regarding my first point, what I mean is that : if you statically link your libApp.so with ssl library, it will no need any dynamic library dependencies, which is probably what you want. But your libApp.so will be loaded by a program. If this program also uses SSL (direct access, not through your libApp.so library), and performs a dynamic link, you will still need the ssl.so to run your application, even if your dll is statically linked with it.

Regards,
Brice


Le mar. 5 nov. 2019 à 18:24, Aijaz Baig <[hidden email]> a écrit :
ldd libAPP.so does NOT have any reference to libSSL.so or for that matter any SSL library. Which is why I had to use nm to check for SSL related symbols

On Mon, Nov 4, 2019 at 6:31 PM Floodeenjr, Thomas <[hidden email]> wrote:

To check if you are linked statically or dynamically, what does ldd tell you? (ldd libAPP.so) Your library should not have a dependency on libssl.so or libcrypto.so if you are linked statically.

 

-Tom

 

From: openssl-users [mailto:[hidden email]] On Behalf Of Aijaz Baig
Sent: Sunday, November 3, 2019 11:30 PM
To: [hidden email]
Subject: static linking libssl and libcrypto

 

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 $@

-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


--

Best Regards,
Aijaz Baig