Re: Static linking libssl.a and libcrypto.a on Linux x64 fails
> Actually, that is also the format and mechanism with Microsoft Win32 tools, > they just use the DOS-like file name "foo.lib" instead of "libfoo.a" to > maintain makefile compatibility with their older Intel OMF-based toolchains. > The object files inside > the archive are in COFF format, as they seem to > have used Unix tools to bring up the initial "NT" operating system internally > back before the initial 1993 release. On some platforms, where objects can be > relinked, the constituent object files > produced by compiling source files are sometimes combined into a single large > object. This is most often seen on AIX, which uses IBM's XCOFF object format > (an enhanced COFF); XCOFF supports relinking objects, so you can bundle > objects up this way and save some time in symbol resolution when you link > against the library later. But even on AIX this is commonly seen with dynamic > libraries and relatively rare for static ones. As I mentioned earlier in my reply to Micheal, I would want to create a single archive that is a self contained 'package' (if you will) that alone would suffice for any application that requires openssl functionality. I've created certain wrappers over the original SSL APIs and the object files that contain this functionality (let's call this collectively as libapp.a) would be 'bundled' along with libssl.a and libcrypto.a. So as mike suggested, I'll combine the whole into a new shiny 'libappssl.a' and all that the application has to be is to pass this to the platform linker (which BTW is posix compliant) and that's all he requires. > Normally the linker isn't even involved in creating a static library. You > compile sources to objects, and then use ar(1) to create the static library. > The makefile you posted to StackOverflow doesn't include this step, so it's > hard to tell what exactly you're doing. That StackOverflow question contains yet another link that points to another question (which I had asked about creating the library). The Makefile for that library contains this at the final linking (or archiving) stage: libAPP.a: $(obj) @ar rcs $@ $^ #$(LINK.c) -shared $^ -o $@ I was creating a shared library earlier but now I am creating a static archive from the object files. > Note: I seem to recall from a long time ago that GNU ar can combine static > libraries directly (without all those temporary file names). > In BinUtils 2.25 this was apparently done by invoking ar in "MRI > compatibility mode" and using the script command "ADDLIB" inside the provided > MRI-style linker script. > For more details see the "ar scripts" part of the full GNU BinUtils TexInfo > manual. > Enjoy > Jakob Well, I'll take a look however Mike's method is pretty easy enough to follow. However, what I am concerned with is, which other libraries do I need to archive (except libc which seems to be obvious I assume) to allow libssl and libcrypto to run on a stripped down system that resembles Linux (aka is POSIX compliant)? Regards, Aijaz On Thu, Nov 14, 2019 at 6:28 AM Aijaz Baig wrote: > > Thank you for the suggestion. Will try that. > > Regarding the static library, the term 'linking' I used was more tongue in > cheek but nonetheless. However my current concern here is meeting libSSL and > libCrypto's dependencies on host libraries on Linux platform. For instance, > when I talked about 'linking' errors with respect to symbols like 'dlopen', > so as I mentioned, I had to specify '-ldl' and '-lz' to the gcc linker that > suggests a dynamic dependency on these platform libraries. > > I was trying to understand the components that would be needed to package the > whole shebang into an archive which I can later 'just run' on a similar Linux > system that has been completely stripped down for purposes of size and speed > > Is there a way to do that? > > On Wed, Nov 13, 2019 at 8:04 PM Michael Wojcik > wrote: >> >> > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf >> > Of Aijaz Baig >> > Sent: Wednesday, November 13, 2019 01:45 >> >> > 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). >> >> You can't link anything into a Linux static library, technically. >> >> ELF static libraries, like the older UNIX static libraries they're descended >> from, are just collections of object files, possibly with some additional >> metadata. (In BSD 4.x, for example, libraries often had an index member >> added using the ranlib utility, so that the linker didn't have to search the >> entire library for each symbol.) >> >> On some pla
Re: Static linking libssl.a and libcrypto.a on Linux x64 fails
Thank you for the suggestion. Will try that. Regarding the static library, the term 'linking' I used was more tongue in cheek but nonetheless. However my current concern here is meeting libSSL and libCrypto's dependencies on host libraries on Linux platform. For instance, when I talked about 'linking' errors with respect to symbols like 'dlopen', so as I mentioned, I had to specify '-ldl' and '-lz' to the gcc linker that suggests a dynamic dependency on these platform libraries. I was trying to understand the components that would be needed to package the whole shebang into an archive which I can later 'just run' on a similar Linux system that has been completely stripped down for purposes of size and speed Is there a way to do that? On Wed, Nov 13, 2019 at 8:04 PM Michael Wojcik < michael.woj...@microfocus.com> wrote: > > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On > Behalf Of Aijaz Baig > > Sent: Wednesday, November 13, 2019 01:45 > > > 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). > > You can't link anything into a Linux static library, technically. > > ELF static libraries, like the older UNIX static libraries they're > descended from, are just collections of object files, possibly with some > additional metadata. (In BSD 4.x, for example, libraries often had an index > member added using the ranlib utility, so that the linker didn't have to > search the entire library for each symbol.) > > On some platforms, where objects can be relinked, the constituent object > files produced by compiling source files are sometimes combined into a > single large object. This is most often seen on AIX, which uses IBM's XCOFF > object format (an enhanced COFF); XCOFF supports relinking objects, so you > can bundle objects up this way and save some time in symbol resolution when > you link against the library later. But even on AIX this is commonly seen > with dynamic libraries and relatively rare for static ones. > > Normally the linker isn't even involved in creating a static library. You > compile sources to objects, and then use ar(1) to create the static > library. The makefile you posted to StackOverflow doesn't include this > step, so it's hard to tell what exactly you're doing. > > But in any case, linking a static library against another static library > is essentially a no-op. > > What you *can* do, if you don't want to have to list your library and the > OpenSSL libraries when linking your application, is combine multiple static > libraries into a single one - provided the object names don't conflict. > This is straightforward: > > $ mkdir tmp; cd tmp > $ ar x /path/to/libssl.a > $ ar x /path/to/libcrypto.a > $ cp /path/to/your/objects/*.o . > $ ar c ../your-library.a *.o > $ cd .. > $ rm -rf tmp > > (Untested, but see the ar manpage if you run into issues.) > > That should create a single archive library containing all the objects > from the three input libraries. Again, it relies on there being no filename > clashes among the objects; if there are, you'll have to rename some of them. > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > > > -- Best Regards, Aijaz Baig
Static linking libssl.a and libcrypto.a on Linux x64 fails
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
Re: static linking libssl and libcrypto
Ok. Got it. Thanks
On Wed, Nov 6, 2019 at 1:41 PM Brice André 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 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 <
>> thomas_floodee...@mentor.com> 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:openssl-users-boun...@openssl.org] *On
>>> Behalf Of *Aijaz Baig
>>> *Sent:* Sunday, November 3, 2019 11:30 PM
>>> *To:* openssl-users@openssl.org
>>> *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 $@
>>>
>>> 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
>>
>
--
Best Regards,
Aijaz Baig
Re: static linking libssl and libcrypto
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 <
thomas_floodee...@mentor.com> 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:openssl-users-boun...@openssl.org] *On
> Behalf Of *Aijaz Baig
> *Sent:* Sunday, November 3, 2019 11:30 PM
> *To:* openssl-users@openssl.org
> *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 $@
>
> 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
Re: static linking libssl and libcrypto
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é 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 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
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 $@
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
