openssl

History

Dr. Stephen Henson 130832150c Fixes for Win32 build. This is mostly a work around for the old VC++ problem that it treats func() as func(void). Various prototypes had been added to 'compare' function pointers that triggered this. This could be fixed by removing the prototype, adding function pointer casts to every call or changing the passed function to use the expected arguments. I mostly did the latter. The mkdef.pl script was modified to remove the typesafe functions which no longer exist. Oh and some functions called OPENSSL_freeLibrary() were changed back to FreeLibrary(), wonder how that happened :-)		2000-06-21 02:25:30 +00:00
..
.cvsignore	Ignore lib and Makefile.save.	2000-04-14 23:37:44 +00:00
dso.h	Currently the DSO_METHOD interface has one entry point to bind all	2000-06-16 10:45:36 +00:00
dso_dl.c	Currently the DSO_METHOD interface has one entry point to bind all	2000-06-16 10:45:36 +00:00
dso_dlfcn.c	Currently the DSO_METHOD interface has one entry point to bind all	2000-06-16 10:45:36 +00:00
dso_err.c	Currently the DSO_METHOD interface has one entry point to bind all	2000-06-16 10:45:36 +00:00
dso_lib.c	Currently the DSO_METHOD interface has one entry point to bind all	2000-06-16 10:45:36 +00:00
dso_null.c	Currently the DSO_METHOD interface has one entry point to bind all	2000-06-16 10:45:36 +00:00
dso_openssl.c	This is a set of startup code for the DSO support, it's not yet linked into	2000-04-04 21:57:11 +00:00
dso_win32.c	Fixes for Win32 build.	2000-06-21 02:25:30 +00:00
Makefile.ssl	Enable DSO support on alpha (OSF1), cc and gcc.	2000-06-13 12:59:38 +00:00
README	Currently the DSO_METHOD interface has one entry point to bind all	2000-06-16 10:45:36 +00:00

README

TODO
----

Find a way where name-translation can be done in a way that is
sensitive to particular methods (ie. generic code could still do
different path/filename substitutions on win32 to what it does on
*nix) but doesn't assume some canonical form. Already one case
exists where the "blah -> (libblah.so,blah.dll)" mapping doesn't
suffice. I suspect a callback with an enumerated (or string?)
parameter could be the way to go here ... DSO_ctrl the callback
into place and it can be invoked to handle name translation with
some clue to the calling code as to what kind of system it is.

NOTES
-----

I've checked out HPUX (well, version 11 at least) and shl_t is
a pointer type so it's safe to use in the way it has been in
dso_dl.c. On the other hand, HPUX11 support dlfcn too and
according to their man page, prefer developers to move to that.
I'll leave Richard's changes there as I guess dso_dl is needed
for HPUX10.20.