openssl

History

Geoff Thorpe 1a797ac67c * This adds some checking to the 'dlfcn' DSO_METHOD that at least lets

it cope with OpenBSD which doesn't understand "RTLD_NOW".
* Added the dso_scheme config string entry for OpenBSD-x86 to give it
  DSO support.
* 'make update' that has also absorbed some of Steve's mkstack changes
  for the ASN-related macros.

2000-06-21 14:12:25 +00:00

.cvsignore

Ignore lib and Makefile.save.

2000-04-14 23:37:44 +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

* This adds some checking to the 'dlfcn' DSO_METHOD that at least lets

2000-06-21 14:12:25 +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

dso.h

Currently the DSO_METHOD interface has one entry point to bind all

2000-06-16 10:45:36 +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.