ยปCore Development>Code coverage>Python/dynload_next.c

Python code coverage for Python/dynload_next.c

#countcontent
1n/a
2n/a/* Support for dynamic loading of extension modules on Mac OS X
3n/a** All references to "NeXT" are for historical reasons.
4n/a*/
5n/a
6n/a#include "Python.h"
7n/a#include "importdl.h"
8n/a
9n/a#include <mach-o/dyld.h>
10n/a
11n/aconst char *_PyImport_DynLoadFiletab[] = {".so", NULL};
12n/a
13n/a/*
14n/a** Python modules are Mach-O MH_BUNDLE files. The best way to load these
15n/a** is each in a private namespace, so you can load, say, a module bar and a
16n/a** module foo.bar. If we load everything in the global namespace the two
17n/a** initbar() symbols will conflict.
18n/a** However, it seems some extension packages depend upon being able to access
19n/a** each others' global symbols. There seems to be no way to eat our cake and
20n/a** have it, so the USE_DYLD_GLOBAL_NAMESPACE define determines which behaviour
21n/a** you get.
22n/a*/
23n/a
24n/a#ifdef USE_DYLD_GLOBAL_NAMESPACE
25n/a#define LINKOPTIONS NSLINKMODULE_OPTION_BINDNOW|NSLINKMODULE_OPTION_RETURN_ON_ERROR
26n/a#else
27n/a#define LINKOPTIONS NSLINKMODULE_OPTION_BINDNOW| \
28n/a NSLINKMODULE_OPTION_RETURN_ON_ERROR|NSLINKMODULE_OPTION_PRIVATE
29n/a#endif
30n/adl_funcptr _PyImport_FindSharedFuncptr(const char *prefix,
31n/a const char *shortname,
32n/a const char *pathname, FILE *fp)
33n/a{
34n/a dl_funcptr p = NULL;
35n/a char funcname[258];
36n/a NSObjectFileImageReturnCode rc;
37n/a NSObjectFileImage image;
38n/a NSModule newModule;
39n/a NSSymbol theSym;
40n/a const char *errString;
41n/a char errBuf[512];
42n/a
43n/a PyOS_snprintf(funcname, sizeof(funcname), "_%.20s_%.200s", prefix, shortname);
44n/a
45n/a#ifdef USE_DYLD_GLOBAL_NAMESPACE
46n/a if (NSIsSymbolNameDefined(funcname)) {
47n/a theSym = NSLookupAndBindSymbol(funcname);
48n/a p = (dl_funcptr)NSAddressOfSymbol(theSym);
49n/a return p;
50n/a }
51n/a#endif
52n/a rc = NSCreateObjectFileImageFromFile(pathname, &image);
53n/a switch(rc) {
54n/a default:
55n/a case NSObjectFileImageFailure:
56n/a case NSObjectFileImageFormat:
57n/a /* for these a message is printed on stderr by dyld */
58n/a errString = "Can't create object file image";
59n/a break;
60n/a case NSObjectFileImageSuccess:
61n/a errString = NULL;
62n/a break;
63n/a case NSObjectFileImageInappropriateFile:
64n/a errString = "Inappropriate file type for dynamic loading";
65n/a break;
66n/a case NSObjectFileImageArch:
67n/a errString = "Wrong CPU type in object file";
68n/a break;
69n/a case NSObjectFileImageAccess:
70n/a errString = "Can't read object file (no access)";
71n/a break;
72n/a }
73n/a if (errString == NULL) {
74n/a newModule = NSLinkModule(image, pathname, LINKOPTIONS);
75n/a if (newModule == NULL) {
76n/a int errNo;
77n/a const char *fileName, *moreErrorStr;
78n/a NSLinkEditErrors c;
79n/a NSLinkEditError( &c, &errNo, &fileName, &moreErrorStr );
80n/a PyOS_snprintf(errBuf, 512, "Failure linking new module: %s: %s",
81n/a fileName, moreErrorStr);
82n/a errString = errBuf;
83n/a }
84n/a }
85n/a if (errString != NULL) {
86n/a PyErr_SetString(PyExc_ImportError, errString);
87n/a return NULL;
88n/a }
89n/a#ifdef USE_DYLD_GLOBAL_NAMESPACE
90n/a if (!NSIsSymbolNameDefined(funcname)) {
91n/a /* UnlinkModule() isn't implemented in current versions, but calling it does no harm */
92n/a /* NSUnLinkModule(newModule, FALSE); removed: causes problems for ObjC code */
93n/a PyErr_Format(PyExc_ImportError,
94n/a "Loaded module does not contain symbol %.200s",
95n/a funcname);
96n/a return NULL;
97n/a }
98n/a theSym = NSLookupAndBindSymbol(funcname);
99n/a#else
100n/a theSym = NSLookupSymbolInModule(newModule, funcname);
101n/a if ( theSym == NULL ) {
102n/a /* NSUnLinkModule(newModule, FALSE); removed: causes problems for ObjC code */
103n/a PyErr_Format(PyExc_ImportError,
104n/a "Loaded module does not contain symbol %.200s",
105n/a funcname);
106n/a return NULL;
107n/a }
108n/a#endif
109n/a p = (dl_funcptr)NSAddressOfSymbol(theSym);
110n/a return p;
111n/a}