Changes between Version 293 and Version 294 of CygwinPort


Ignore:
Timestamp:
04/02/13 18:55:37 (9 years ago)
Author:
jpflori
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • CygwinPort

    v293 v294  
    486486* Ive cleaned up my rebase database and rebased everything and it seems most of the remaining fork errors I had last time are gone.
    487487
    488 === Testing Sage 5.7.beta2 on 32 bits Windows 7 ===
     488=== Testing Sage 5.9.beta2 on 32 bits Windows 7 ===
    489489* I launched the build yesterday night and found it back this morning having installed most of the spkg, it just failed during compilation of the Sage library because of a fork error, that was expected. So to summarize, great news!
    490490* Cygwin has recently (early 2013) integrated Python 2.7 which happens to be the same version that Sage ships. That's a problem because on Cygwin libpython2.7.dll is installed in the "bin" directory and we don't include it in LD_LIBRARY_PATH. That would not be a problem because most of Cygwin dll system uses the PATH var where "bin" is present, but dlopen  does not use PATH, so the _ctypes module of python which uses it to load libpython sees an empty LD_LIBRARY_PATH, then looks for default dirs, which point to /usr/lib,bin, and if you have a system wide python 2.7 installed, loads the libpython2.7 from there at a different address than the initial libpython loaded by Sage's python initially. And then when you try to fork(), Cygwin whines because it's using the dlopened libpython, but the libraries loaded during fork use PATH which points to the Sage's libpython (already loaded once, but whatever), so the base address are different and BOOM (not that this base address conflict is not a problem for dlopen at first...). This is now #14380/