Hi Qadeer,
I believe you can just statically link the openssl libraries while creating a dynamic library. Your dynamic library will just be bigger than it would be otherwise. The libraries that are named *.a are the static versions. Everything I'm about to say applies to the GNU tool set on Mac OS X, so if you're using something else, this might not apply.
If you want to link against your static libssl.a, you basically have two options.
1) Specify -lssl to the linker and add the path to your version to the library search paths
2) Add $YOUR_LIB_PATH/libssl.a to the list of files to link.
Problems with these approaches:
(1) allows the linker to expand the filename and do the search. My experience has been that it searches its own set of paths before it searched the ones you add, and /usr/lib gets searched ahead of your path. When it finds libssl.dylib, it dynamically links against that, so your version of libssl.a gets ignored. (This may be different on other Unix platforms, but this is what I observed on the Mac.) I don't see that there is any way to force your search paths to be ahead of the hardwired paths. (You might carefully read the linker man page in case I missed something.)
(2) does the correct thing. It statically links against your version of libssl.a. It also acts just like it found the library because of a -lssl on the linker command line. (Only the functions that are required are pulled into your executable, NOT the entire library contents.) Again, check out the linker man page. They tell you about this behavior there. The problem here is that if you use Xcode, then when you drag a static library onto your project, say $YOUR_LIB_PATH/libssl.a, Xcode very (un)cleverly adds -lssl to its linker command line. This means that the linker is going to search for libssl.[a | dylib] and use the first one it finds, and you're out of luck. When I ran across this (while trying to use Xcode to build the openssl test program as a statically linked executable) I finally built the linker line by hand, explicitly naming the static libraries that I wanted, and executed it at the shell. That's probably not what you want to do.
I need to solve this problem for my project, because we think we want to use Xcode for C/C++ development. What I think I am going to do is to rename all of the third party libraries from libXxxx.* to libXxxx_MyCompany.*. This after I have run the make procedure that comes with the source distribution, and the corresponding make install. There are issues with this if your third party libraries depend on other third party libraries (The libxml2/libxslt/xmlsec trio come to mind), because they expect the unadorned names when they link against each other. If nothing else, I can have an installation directory that contains the libraries with their unadorned names, and a second location that has copies of them (or links if you are only on the Mac or another Unix platform) that use the adorned names. Then when I use Xcode for my project, and I need to link against my version of libssl.a, I can drag $MY_LIB_PATH/libssl_MyCompany.a onto the project, let Xcode stupidly turn that into -lssl_MyCompany, and my link should work correctly.
Another thing to consider is that you have libssl.a and libssl.dylib. If you rename them to libssl_YourCompany.a and libssl_YourCompany.dylib, I have no idea which one the linker will find. (I'm going to delete all the dynamic libraries after the make install because I only want to link statically.) You probably need some extra stuff to distinguish static from dynamic. Maybe libssl_s_YourCompany.a and libssl_d_YourCompany.dylib. Yuck.
Hope it helps, Rush
Qadeer Baig wrote:
Hi,
I am using openssl in an application (this application actually is a ".dylib" on Mac OSX). Currently I am linking openssl calls by using "-lssl -lcrypto" linker options. Since this links openssl calls dynamcally therefor I can only use resulting application on the computers where "libssl.dylib" and "libcrypto.dylib" are already installed.
Now what I want is that openssl is statically linked into my application (dll, ".dylib" on OSX) so that "libssl.dylib" and "libcrypto.dylib" are not required on the machines where my application is used. What linker options will I use?, XCode internally uses gcc (I believe). It will be of great help if someone can give a simple make file (or a simple xcode project).
I have following libraries available: 1. libssl.dylib 2. libcrypto.dylib 3. libssl.a 4. libcrypto.a
I think ".a" libraries will be used for static linking but how(?) so that the resulting application is a still a ".dylib".
Any help will be highly appreciated.
Thanks and regards,
-- Qadeer ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
