summaryrefslogtreecommitdiff
path: root/crypto/dso/dso_dlfcn.c
Commit message (Collapse)AuthorAgeFilesLines
* Remove dead code from cryptoMatt Caswell2015-03-171-4/+3
| | | | | | | Some miscellaneous removal of dead code from lib crypto. Reviewed-by: Richard Levitte <levitte@openssl.org> (cherry picked from commit b7573c597c1932ef709b2455ffab47348b5c54e5)
* Run util/openssl-format-source -v -c .Matt Caswell2015-01-221-355/+339
| | | | Reviewed-by: Tim Hudson <tjh@openssl.org>
* Additional comment changes for reformat of 1.0.1Matt Caswell2015-01-221-1/+1
| | | | Reviewed-by: Tim Hudson <tjh@openssl.org>
* dlfcn: always define _GNU_SOURCEKurt Roeckx2014-12-301-4/+2
| | | | | | | We need this for the freebsd kernel with glibc as used in the Debian kfreebsd ports. There shouldn't be a problem defining this on systems not using glibc. Reviewed-by: Richard Levitte <levitte@openssl.org>
* Fix a wrong parameter count ERR_add_error_dataJanpopan2014-05-191-1/+1
|
* add android support to DSO (from HEAD)Dr. Stephen Henson2011-06-091-1/+2
|
* dso_dlfcn.c: make it work on Tru64 4.0 [from HEAD].Andy Polyakov2011-02-121-0/+1
|
* dso_dlfcn.c: fix compile failure on Tru64 [from HEAD].Andy Polyakov2010-03-291-0/+3
|
* Prevent aliasing warningDr. Stephen Henson2009-10-041-4/+7
|
* Update from HEAD.Dr. Stephen Henson2009-07-161-3/+3
|
* Handle OSX ".dynlib" DSO extension.Dr. Stephen Henson2009-07-151-4/+13
|
* More type-checking.Ben Laurie2008-06-041-8/+8
|
* Last dso_dlfcn.c check-in said "Use Dl_info only on systems where it isAndy Polyakov2008-01-041-6/+7
| | | | | | known to exist. It does not exist on AIX 4.3.3, AIX 5.1, SCO 5, or Cygwin" and disabled it on banch of systems it's known to exists, such as FreeBSD, Solaris, 64-bit HP-UX, MacOS X. Get it straight.
* check if pointer is != NULL before dereferencing it (Coverity CID 40)Nils Larsch2007-04-021-3/+2
|
* Use Dl_info only on systems where it is known to exist. It does notUlf Möller2006-04-111-1/+5
| | | | exist on AIX 4.3.3, AIX 5.1, SCO 5, or Cygwin.
* uncomment; that one slipped throughUlf Möller2006-04-111-1/+1
|
* improve make dclean to remove files generated during buildUlf Möller2006-04-111-0/+2
| | | | | | PR: 1308 Submitted by: Oliver Tappe <zooey@hirschkaefer.de> Reviewed by: Ulf Moeller
* fix problems found by coverity: remove useless codeNils Larsch2006-03-151-1/+1
|
* "Relax" prototype and rename DSO_global_lookup_func to DSO_global_lookup.Andy Polyakov2006-01-021-6/+5
|
* Add DSO_global_lookup_func implementation. See commentary in dso_lib.cAndy Polyakov2005-12-301-1/+17
| | | | for further details.
* commentsUlf Möller2005-12-181-3/+3
|
* Eliminate gcc -pedantic warnings.Andy Polyakov2005-06-091-1/+6
|
* _GNU_SOURCE needs to be defined before any standard header.Richard Levitte2005-06-061-5/+10
|
* New function, DSO_pathbyaddr, to find pathname for loaded shared objectAndy Polyakov2005-06-051-1/+68
| | | | | by an address within it. Tested on Linux, Solaris, IRIX, Tru64, Darwin, HP-UX, Win32, few BSD flavors...
* fix "dereferencing type-punned pointer will break strict-aliasing rules"Nils Larsch2005-05-191-2/+2
| | | | warning when using gcc 4.0
* Avoid warnings.Dr. Stephen Henson2005-05-121-1/+1
|
* Make sure DSO-dlfcn works properly on SunOS4.Richard Levitte2003-06-121-1/+5
| | | | PR: 585
* Add the possibility to have symbols loaded globally with DSO.Richard Levitte2003-06-111-1/+7
|
* There's an ongoing project to bring some kind of path selectionRichard Levitte2002-07-151-1/+71
| | | | | | | | | | | 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.
* Set DLOPEN_FLAG the same way on NetBSD as on OpenBSD.Richard Levitte2002-05-291-1/+1
| | | | PR: 58, submitted by andrew@cis.uoguelph.ca
* At least for the two common Unixly DSO loading methods, include theRichard Levitte2001-11-151-3/+3
| | | | system error in the error text.
* 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.
* For the operating systems where it matters, it is sometimes good toRichard Levitte2000-10-261-7/+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-23/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* 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.
* * This adds some checking to the 'dlfcn' DSO_METHOD that at least letsGeoff Thorpe2000-06-211-2/+22
| | | | | | | | 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.
* Currently the DSO_METHOD interface has one entry point to bind allGeoff Thorpe2000-06-161-15/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | "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-1/+47
| | | | | | | | | | | | | 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 helps make the DSO stuff more portable;Geoff Thorpe2000-04-061-0/+2
| | | | | | | | | * "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.
* This is a set of startup code for the DSO support, it's not yet linked intoGeoff Thorpe2000-04-041-0/+179
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.
View Lorry Controller Status