Changes between Version 109 and Version 110 of Cygwin64Port


Ignore:
Timestamp:
07/10/18 16:44:32 (3 months ago)
Author:
embray
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Cygwin64Port

    v109 v110  
    9494
    9595This bug can hypothetically affect other code, especially code using Python's `multiprocessing.Pool` (since calling `fork()` from a thread is exactly something it tends to do).  But it comes up most commonly in the doc build.
     96
     97==== Problems with git ====
     98
     99Depending on the exact library versions, using the `git` from Cygwin can get messed up if you're in the Sage shell (e.g. in `sage -sh`).  The reasons for this are detailed in #25816, but in short it's an example of DLL hell arising from the fact that `git` (as you may know) is actually built out of a whole mess of different executables, all of which are installed in Cygwin under `/usr/libexec/git-core`.  The Sage shell messes with the `$PATH` variable such that the smaller programs that make up git can end up loading some of their dependent DLLs from `$SAGE_LOCAL`, which can break things if the library versions don't happen to be in sync.  A workaround is to copy the necessary DLLs from `/usr/bin` into `/usr/libexec/git-core`--specifically only those DLLs that might be overridden by Sage.  As of writing the only two such DLLs are:
     100
     101* `cygiconv-2.dll`
     102* `cygpcre-1.dll`
     103
     104However, a generic way to make this fixup is:
     105
     106{{{
     107#!sh
     108for dllname in $(cygcheck.exe /usr/libexec/git-core/*.exe | grep "$(cygpath -w -a $SAGE_LOCAL | sed 's/\\/\\\\/g')" | sed 's|.*\\\(.\+\.dll\)|\1|' | sort | uniq); do
     109    cp /usr/bin/$dllname /usr/libexec/git-core
     110done
     111}}}
    96112
    97113==== Difficulties debugging with GDB ====