Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Trac #30149: Cygwin: problem with DLL search order when using system …
…Python I noticed a problem when trying to run the tests for the latest Sage, that the wrong version of `libR.dll` was being loaded, because I have R installed via Sage, but I also have the R package for Cygwin installed. My path starts with: {{{ /home/embray/src/sagemath/sage/local/lib/R/lib:/home/embray/src/sagemath /sage/local/lib:/home/embray/src/sagemath/sage/build/bin:/home/embray/sr c/sagemath/sage/src/bin:/home/embray/src/sagemath/sage/local/bin:/usr/lo cal/bin:/usr/bin }}} so when importing `rpy2` it should link with the `libR.dll` that's in `$SAGE_LOCAL/lib/R/lib`. Normally this has been the case. But when using the system Python this is not so. This is because according to the standard [https://docs.microsoft.com/en-us/previous- versions/7d83bc18(v=vs.140)?redirectedfrom=MSDN DLL search path] the first place it looks is: > The directory where the executable module for the current process is located. Well, when running the system Python that's `/usr/bin` where `python3.7m.exe` lives. However, that's also where the system's `libR.dll` lives. This is just an example, but it's a broader problem: For any DLL linked to by a compiled Python module, it will always privilege the one in `/usr/bin` over a copy provided by Sage. What we might have to do is, at least on Cygwin, when creating the venv it should actually copy the Python executable instead of just symlinking to it. I believe venv has an option for this. URL: https://trac.sagemath.org/30149 Reported by: embray Ticket author(s): Erik Bray Reviewer(s): Matthias Koeppe
- Loading branch information