aboutsummaryrefslogtreecommitdiffstats
path: root/crypto/dso/dso_dl.c
Commit message (Collapse)AuthorAgeFilesLines
* misspellings fixes by https://github.com/vlajos/misspell_fixerVeres Lajos2013-09-051-2/+2
|
* "Relax" prototype and rename DSO_global_lookup_func to DSO_global_lookup.Andy Polyakov2006-01-021-3/+3
|
* Add DSO_global_lookup_func implementation. See commentary in dso_lib.cAndy Polyakov2005-12-301-1/+11
| | | | for further details.
* Eliminate gcc -pedantic warnings.Andy Polyakov2005-06-091-1/+6
|
* Allow for dso load by explicit path on HP-UX.Andy Polyakov2005-06-091-1/+2
|
* New function, DSO_pathbyaddr, to find pathname for loaded shared objectAndy Polyakov2005-06-051-1/+26
| | | | | by an address within it. Tested on Linux, Solaris, IRIX, Tru64, Darwin, HP-UX, Win32, few BSD flavors...
* Third argument to shl_load() is "long address", not a pointer.Lutz Jänicke2003-01-081-1/+1
| | | | | | | (Didn't influence functionality, as on HP-UX 32bit the NULL pointer is a 32bit 0-value and thus is identical to the required 0L.) PR: 443
* There's an ongoing project to bring some kind of path selectionRichard Levitte2002-07-151-1/+69
| | | | | | | | | | | 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.
* At least for the two common Unixly DSO loading methods, include theRichard Levitte2001-11-151-3/+6
| | | | system error in the error text.
* Use one address consistently.Richard Levitte2001-07-051-1/+1
|
* This change to the "dl", "dlfcn", and "win32" DSO_METHODs adds the filenameGeoff Thorpe2001-04-251-0/+3
| | | | | or symbol name to the error stack in the event a load or bind operation failed.
* shl_load() also needs to load along a path given through anRichard Levitte2000-11-071-1/+1
| | | | environment variable, SHLIB_PATH. This change makes that possible.
* On HP-UX, at least when shl_* are used, the libraries have theRichard Levitte2000-10-261-7/+12
| | | | extension .sl instead of .so.
* For the operating systems where it matters, it is sometimes good toRichard Levitte2000-10-261-8/+15
| | | | | | 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.
* This changes the behaviour of the DSO mechanism for determining anGeoff Thorpe2000-10-261-17/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Pointer error correctedRichard Levitte2000-10-221-2/+2
|
* None of the DSO_METHOD's were handling anything except generic messages.Geoff Thorpe2000-10-081-26/+2
| | | | These are now processed inside DSO_ctrl() itself.
* Currently the DSO_METHOD interface has one entry point to bind allGeoff Thorpe2000-06-161-16/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | "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).
* This case in the "dso_unload" handlers should not be reported as an error -Geoff Thorpe2000-04-251-4/+1
| | | | | | | | | | | | | 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).
* This change facilitates name translation for shared libraries. TheGeoff Thorpe2000-04-191-2/+42
| | | | | | | | | | | | | 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.
* Constification, and a silly mistake in the comments.Geoff Thorpe2000-04-061-4/+4
|
* This is a set of startup code for the DSO support, it's not yet linked intoGeoff Thorpe2000-04-041-0/+182
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.
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-11 22:01:30 +0000