| 1 |
|
|---|
| 2 | /* Support for dynamic loading of extension modules on Mac OS X
|
|---|
| 3 | ** All references to "NeXT" are for historical reasons.
|
|---|
| 4 | */
|
|---|
| 5 |
|
|---|
| 6 | #include "Python.h"
|
|---|
| 7 | #include "importdl.h"
|
|---|
| 8 |
|
|---|
| 9 | #include <mach-o/dyld.h>
|
|---|
| 10 |
|
|---|
| 11 | const struct filedescr _PyImport_DynLoadFiletab[] = {
|
|---|
| 12 | {".so", "rb", C_EXTENSION},
|
|---|
| 13 | {"module.so", "rb", C_EXTENSION},
|
|---|
| 14 | {0, 0}
|
|---|
| 15 | };
|
|---|
| 16 |
|
|---|
| 17 | /*
|
|---|
| 18 | ** Python modules are Mach-O MH_BUNDLE files. The best way to load these
|
|---|
| 19 | ** is each in a private namespace, so you can load, say, a module bar and a
|
|---|
| 20 | ** module foo.bar. If we load everything in the global namespace the two
|
|---|
| 21 | ** initbar() symbols will conflict.
|
|---|
| 22 | ** However, it seems some extension packages depend upon being able to access
|
|---|
| 23 | ** each others' global symbols. There seems to be no way to eat our cake and
|
|---|
| 24 | ** have it, so the USE_DYLD_GLOBAL_NAMESPACE define determines which behaviour
|
|---|
| 25 | ** you get.
|
|---|
|
|---|