e9a68cfbc3
"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).
24 lines
927 B
Text
24 lines
927 B
Text
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.
|
|
|
|
|