Thanks much. Knew all of that from a technology point of view and from other
platforms but did not know the proper Windows/UNIX terms.

I was worried by the assertion that static linking to .lib's and the use of
DLLs was inconsistent.

> at runtime the OS finds those .dll's 
> using moderately complicated search rules, which can be an issue 
> if you have multiple versions in different places

Yes, and I found that various products I have licensed or trialed over the
past few years have each installed their own OpenSSL DLLs of various
versions in various places. SSLeay_version(SSLEAY_VERSION) is a big help in
figuring out which DLL is actually getting used.

> If you link with lib/VC/* (or lib/MinGW/*) you get 
> implicit dynamic linking. If you link with 
> lib/VC/static/* you get static linking.

Thanks. Did not exactly understand that point. I am in fact using lib/VC/*.
I may change that to MinGW so that the intention is more obvious.

Charles

-----Original Message-----
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson
Sent: Tuesday, October 16, 2012 5:53 PM
To: openssl-users@openssl.org
Subject: RE: Building an "exportable" OpenSSL application

> From: owner-openssl-us...@openssl.org On Behalf Of Charles Mills
> Sent: Tuesday, 16 October, 2012 11:41

> > If you are linking to OpenSSL DLLs, then your application 
> isn't statically
> > linked against OpenSSL.  .lib files can simply be 
> references to exports in .dll files.
> 
> This is an important point. Can we be absolutely clear? My 
> picture of how
> this works is that the .lib files contain small stubs so that 
> while the
> application code has the "illusion" of making a static call to
> SSL_whatever() in reality that is a tiny stub that actually 
> calls code in a
> DLL. There is no "functional" code in the .lib, only stubs 
> that link to
> functional code in the DLLS. Am I wrong? This is a critical point.
> 
Yes, plus. To be exact, there are really three ways:

- traditional (since like 1950) static linking, with .lib on Windows 
or .a on Unix containing actual code and static data. The linker 
copies referenced code and data to your Windows .exe or Unix executable.

- "implicit" dynamic linking, with .lib on Windows containing stubs 
that point to code (and sometimes data, but that's usually poor 
practice) in a .dll. This type of .lib is called an import library.
The linker pulls the stubs into your .exe and and also includes a 
list of the .dll files; at runtime the OS finds those .dll's 
using moderately complicated search rules, which can be an issue 
if you have multiple versions in different places, although 
in my (limited) experience the simple solution of putting .dll's 
in the same directory as the .exe always works. On Unix similar 
but there's no import library; you link directly against .so .sl 
etc, and the linker puts the "imports" in the executable. 

- "explicit" dynamic linking: instead just calling XYZ_whatever, 
the source code of the app calls OS routines to get pointers to 
the routines in the dynamic library and then calls using those 
pointers. For Windows the routines are LoadLibrary or a variant 
and GetProcAddress; for Unix they are dlopen and dlsym. This is 
more work, but has the advantage your program can continue if 
the desired dyn lib or routine is not available, instead of dying.

To add to the confusion, "implicit" and "explicit" dynlibs are 
sometimes called "static" and "dynamic", but even a "static" dynlib 
is still dynamic as far as execution is concerned.

> BTW, thanks for the Shining Light Windows build. It's what I am using.
> 
Note the Shining Light builds provide all options. If you link 
with lib/VC/* (or lib/MinGW/*) you get implicit dynamic linking.
If you link with lib/VC/static/* you get static linking. 
Or you can code explicitly and use the .dll's directly.

In most cases dynamic linking is preferable, usually implicit, and 
it sounds like for you especially so, but all options work.


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majord...@openssl.org

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to