Phillip J. Eby wrote: > I don't know. I can see that the split makes sense for prefix/exec-prefix > distinctions, but then again, the disutils will install an entire > distribution in exec-prefix if it contains "impure" parts, so that's > certainly an option here. > > On the other hand, it's not clear to me *why* the lib-dynload/DLLs > directories exist, since it seems to me that that's what exec-prefix is > for. Can you please explain? exec_prefix will point to, say, /usr/i686; it shouldn't be that .so files are directly installed in that location. Instead, Python searches them in EXEC_PREFIX "/lib/python" VERSION "/lib-dynload". > Perhaps somebody can explain why lib-dynload/ and DLLs/ > exist? To have a directory on sys.path where native modules are found. > Perhaps some platforms have to add these directories to some > godforsaken environment variables like LD_LIBRARY_PATH or something? Not to my knowledge, no. lib-dynload was introduced in revision 8976, where it was renamed from "/sharedmodules". This, in turn, was introduced into getpath.c in revision 7775 (and 7776). It was added to Modules/Setup.in in revision 6313, and to Makefile.in in 6321. Unfortunately, the checkin message of 6321 only says More changes to install targets. The notion of a separate makefile variable for shared libraries goes back to Modules/Makefile.pre.in at 4333, which first introduced dynamic loading (in 1994). Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4