Just two small general NITs (Sort of off-topic, as the OP seems to know this):
On 10/17/2012 2:53 AM, Dave Thompson wrote:
... - "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.
NIT 1: On Windows, modern (post 1998) "stub" .libs often contain only a data description of the symbol and how it is listed in the DLLs export table, the actual stub/glue code is then generated on the fly by the linker. Also the stubs have two parts: A single pointer variable tagged to be filled in at runtime by the loader, and an optional jump stub used by code that had not been compiled to know this item would be imported (via __declspec(dllimport) in the header telling the compiler to implicitly reference the pointer variable inline). NIT 2: Importing data is not bad practice per se, but typically requires thecompiler and linker to both know that this is an imported data address,which cannot be serviced via a "jump to real address" proxy stub likefunctions can. This can expose bugs and shortcomings in the toolchain(compiler/linker). For the PE file format (Win32/Win64/WinCE): Many versions of the GNU toolchain play nasty tricks with this file format due to a misunderstandingof its more subtle points. For Visual C, the special "delayload" linker/runtimefeature does not work well for data items, as it generates special stubs that loadresolve the symbol on first call, and this only works for function symbols. For the old Borland/Turbo C/C++ tools there was a bug in some versions messing up the import of the stdin/stdout/stderr variables from the C runtime DLL, causing even very simple programs (like "Hello, stderr") to crash. Because of this (and because some platforms just don't support it at all), it is good practice for portable DLLs to export a functions which returns the address of the data item, thus working around all this breakage. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, 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 ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
