mirror/openssl
2
0
Fork 0
mirror of https://github.com/openssl/openssl.git synced 2024-11-27 05:21:51 +08:00
Code Issues Packages Projects Releases Wiki Activity
3aa477f6ec
openssl/crypto/dso/README

25 lines
927 B
Plaintext
Raw Normal View History

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-05 05:57:11 +08:00
TODO
----
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 18:45:36 +08:00
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.
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-05 05:57:11 +08:00
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.
Reference in New Issue Copy Permalink