> 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
