Rebuild error codes.

Make sure we get the definition of OPENSSL_NO_ERR.

Some older code (never committed) wasn't converted to the new format.
Corrected.

There's an ongoing project to bring some kind of path selection
mechanism to the ENGINE framework. This means there there are going
to be new functionality for the DSO part, and ultimately s

There's an ongoing project to bring some kind of path selection
mechanism to the ENGINE framework. This means there there are going
to be new functionality for the DSO part, and ultimately some way of
merging two file specifications together.

This commit places the merging code into the repository. It's
currently not used anywhere, and hasn't been tested at all. It may be
full of errors, including syntactical ones. Those will be fixed as
promptly as possible.

show more ...

Add a "_up" -> "_up_ref" change to libeay.num that was missing from the
recent changes. Also, do the same change to the DSO_up() function.

Make all configuration macros available for application by making
sure they are available in opensslconf.h, by giving them names starting
with "OPENSSL_" to avoid conflicts with other package

Make all configuration macros available for application by making
sure they are available in opensslconf.h, by giving them names starting
with "OPENSSL_" to avoid conflicts with other packages and by making
sure e_os2.h will cover all platform-specific cases together with
opensslconf.h.

I've checked fairly well that nothing breaks with this (apart from
external software that will adapt if they have used something like
NO_KRB5), but I can't guarantee it completely, so a review of this
change would be a good thing.

show more ...

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 cha

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.

show more ...

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.

A DSO method for VMS was missing, and I had the code lying around...

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

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).

show more ...

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

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.

show more ...

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

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.

show more ...