In part reported by Lynn Gazis <lgazis@IVEA.com>. The rest of the
report is about SHLIB_PATH being ignored. It was decided that using
it would break security.
'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.
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.
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 :-)
"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).
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.
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.
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).
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.
* "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.
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.
