Commit graph

135 commits

Author SHA1 Message Date
Richard Levitte
856d456a71 Make the DSO code for VMS work again. First attempt. 2000-12-31 01:55:46 +00:00
Richard Levitte
e06433d9ba shl_load() also needs to load along a path given through an
environment variable, SHLIB_PATH.  This change makes that possible.
2000-11-07 11:25:26 +00:00
Bodo Möller
02af65b347 avoid memory leak 2000-11-03 15:40:10 +00:00
Geoff Thorpe
7d09713d09 DSO_load() should also work when it is passed a NULL - a new DSO is created
automatically, however some code was still referring to the original
pointer rather than the internal one (and thus to NULL instead of the
created pointer).
2000-10-30 18:47:27 +00:00
Richard Levitte
551e5990d2 On HP-UX, at least when shl_* are used, the libraries have the
extension .sl instead of .so.
2000-10-26 18:42:35 +00:00
Richard Levitte
d9efa3616a For the operating systems where it matters, it is sometimes good to
translate library names by only adding ".so" to them without
prepending them with "lib".  Add the flag DSO_FLAG_NAME_TRANSLATION_EXT_ONLY
for that purpose.
2000-10-26 18:30:34 +00:00
Geoff Thorpe
51c8dc37dd This changes the behaviour of the DSO mechanism for determining an
appropriate filename translation on the host system. Apart from this point,
users should also note that there's a slight change in the API functions
too. The DSO now contains its own to-be-converted filename
("dso->filename"), and at the time the DSO loads the "dso->loaded_filename"
value is set to the translated form. As such, this also provides an impicit
way of determining if the DSO is currently loaded or not. Except, perhaps,
VMS .... :-)

The various DSO_METHODs have been updated for this mechanism except VMS
which is deliberately broken for now, Richard is going to look at how to
fit it in (the source comments in there explain "the issue").

Basically, the new callback scheme allows the filename conversion to
(a) be turned off altogether through the use of the
    DSO_FLAG_NO_NAME_TRANSLATION flag,
(b) be handled in the default way using the default DSO_METHOD's converter
(c) overriden per-DSO by setting the override callback
(d) a mix of (b) and (c) - eg. implement an override callback that;
    (i) checks if we're win32 "if(strstr(dso->meth->name, "win32"))..."
        and if so, convert "blah" into "blah32.dll" (the default is
	otherwise to make it "blah.dll").
    (ii) default to the normal behaviour - eg. we're not on win32, so
         finish with (return dso->meth->dso_name_converter(dso,NULL)).
(e) be retried a number of times by writing a new DSO_METHOD where the
    "dso_load()" handler will call the converter repeatedly. Then the
    custom converter could use state information in the DSO to suggest
    different conversions or paths each time it is invoked.
2000-10-26 17:38:59 +00:00
Richard Levitte
e9a583aa26 Pointer error corrected 2000-10-22 12:47:01 +00:00
Geoff Thorpe
ef76e3dbda DSO_ctrl() changes have removed a couple of DSO_METHOD-specific functions
so I've regenerated the error numbers and strings for the DSO functions.
2000-10-09 01:57:54 +00:00
Geoff Thorpe
75a382bd90 None of the DSO_METHOD's were handling anything except generic messages.
These are now processed inside DSO_ctrl() itself.
2000-10-08 22:36:49 +00:00
Geoff Thorpe
5b0a0544f2 Time to get rid of some rather silly code duplication - some DSO_ctrl()
commands are common to all DSO_METHODs, hence handle them at the top.
2000-10-08 22:32:57 +00:00
Richard Levitte
4e20a4e688 'ranlib' doesn't always run on some systems. That's actually
acceptable, since all that happens if it fails is a library with
an index, which makes linking slower, but still working correctly.
2000-09-25 08:53:15 +00:00
Richard Levitte
4534fb1c86 Unless we cast, thorough compilers will complain 2000-09-18 08:40:55 +00:00
Richard Levitte
62324627aa Use sk_*_new_null() instead of sk_*_new(NULL), since that takes care
of complaints from the compiler about data pointers and function
pointers not being compatible with each other.
2000-09-17 18:21:27 +00:00
Richard Levitte
3aa477f6ec Make sure Compaq C doesn'r complain about dollars, and go around the
incompatibility between function and data pointers.
2000-09-17 14:42:46 +00:00
Richard Levitte
ea4e4149af Make sure dso_vms.c compiles on other operating systems as well. 2000-09-15 22:12:53 +00:00
Richard Levitte
0e05f54516 A DSO method for VMS was missing, and I had the code lying around... 2000-09-15 21:22:50 +00:00
Richard Levitte
a4129c6e33 Add a flag for OpenVMS. 2000-09-15 13:59:30 +00:00
Richard Levitte
62ab514e98 'make update' 2000-09-07 08:46:51 +00:00
Geoff Thorpe
8ba92cfe81 Steve fixed up some strange errors introduced into dso_win32.c, and I'm
just converting some spaces to tabs from his fix. :-)
2000-06-23 17:29:05 +00:00
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
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
Geoff Thorpe
e9a68cfbc3 Currently the DSO_METHOD interface has one entry point to bind all
"symbols" including functions (of all prototypes( and variables. Whilst
casting any function type to another violates ANSI C (I believe), it is
a necessary evil in shared-library APIs. However, it is quite
conceivable that functions in general and data symbols could very well
be represented differently to each other on some systems, as Bodo said;

> Since the function/object distinction is a lot more likely to be
> important on real-life platforms supporting DSO *and* it can be quite
> easily done *and* it will silence compilers that don't like
> assignments from void pointers to function pointer variables, why
> not do it?

I agree. So this change splits the "dso_bind" handler in DSO_METHOD
into "dso_bind_var" and "dso_bind_func". Similarly the exported
function DSO_bind() has been split in two. I've also put together
changes for the various DSO_METHOD implementations, but so far only
DSO_dlfcn() has been tested. BTW: The prototype for dso_bind had been
a bit strange so I've taken the opportunity to change its shape (in
both variations).

Also, the README has been updated - particularly with a note about
using customised native name-translation for shared libraries (and that
you can't do it yet).
2000-06-16 10:45:36 +00:00
Geoff Thorpe
1c4f90a05d Enable DSO support on alpha (OSF1), cc and gcc.
Also, "make update" has added some missing functions to libeay.num,
updated the TABLE for the alpha changes, and updated thousands of
dependancies that have changed from recent commits.
2000-06-13 12:59:38 +00:00
Richard Levitte
26a3a48d65 There have been a number of complaints from a number of sources that names
like Malloc, Realloc and especially Free conflict with already existing names
on some operating systems or other packages.  That is reason enough to change
the names of the OpenSSL memory allocation macros to something that has a
better chance of being unique, like prepending them with OPENSSL_.

This change includes all the name changes needed throughout all C files.
2000-06-01 22:19:21 +00:00
Geoff Thorpe
8c343cf861 another warning. 2000-05-29 04:20:52 +00:00
Geoff Thorpe
e9e6b88b35 oops. 2000-05-29 02:42:57 +00:00
Bodo Möller
22a415478f Add missing #include. 2000-05-01 19:49:41 +00:00
Geoff Thorpe
ebbaebf784 This case in the "dso_unload" handlers should not be reported as an error -
if a DSO_load(NULL,...) operation fails, it will have to call DSO_free() on
the DSO structure it created and that will filter through to this "unload"
call.

If the stack size is "< 1", then the library never actually loaded. To keep
things clean higher up, I'll treat this as a vacuous case without an error.
It makes the error stack easier to follow real world cases, and the error
this ignores was only useful for catching bugs in internal code, not
mismatched calls from applications (which should be handled in the generic
DSO layer).
2000-04-25 08:37:12 +00:00
Geoff Thorpe
b9e6391582 This change facilitates name translation for shared libraries. The
technique used is far from perfect and alternatives are welcome.
Basically if the translation flag is set, the string is not too
long, and there appears to be no path information in the string,
then it is converted to whatever the standard should be for the
DSO_METHOD in question, eg;
    blah --> libblah.so   on *nix, and
    blah --> blah.dll     on win32.

This change also introduces the DSO_ctrl() function that is used
by the name translation stuff.
2000-04-19 21:45:17 +00:00
Bodo Möller
bc36f18117 Ignore lib and Makefile.save. 2000-04-14 23:37:44 +00:00
Richard Levitte
7a807ad8a7 "make update" 2000-04-09 12:52:40 +00:00
Geoff Thorpe
51175595b3 Constification, and a silly mistake in the comments. 2000-04-06 14:54:54 +00:00
Geoff Thorpe
bc2aadad84 This helps make the DSO stuff more portable;
* "no-dso" option available in Configure so that all DSO methods will
  return NULL, overriding any support the platform might otherwise
  have built.
* dlfcn_no_h config string now available rather than just dlfcn. This
  is for platforms that have dlfcn.h functions but do not have (or
  need) the dlfcn.h header file.
2000-04-06 07:09:45 +00:00
Geoff Thorpe
8f4fac7f96 This is a set of startup code for the DSO support, it's not yet linked into
the build process (an upcoming commit no doubt), and is very much *new*
code - what that means is that it compiles ok - usually. It certainly
doesn't mean it runs well or even properly yet. Please don't muck round
with this unless you're looking to help out and hunt bugs. :-)

Currently this code doesn't have any support for controlling the "load"
behaviour (eg. paths, filename translations, etc). That'll be handled
using DSO_ctrl() and various flags, once we work out a sensible set of
flags.
2000-04-04 21:57:11 +00:00