[Ecls-list] Cygwin problems -- serious ones

[Juan Jose Garcia-Ripoll]

Hi everyone,

I have been tracking the cygwin issues along different fronts. My
conclusions are not good, but I might be wrong.

What happens is that cygwin is faking "fork()". Windows does not have it, so
what Cygwin does is to reload the whole executable file and all shared
libraries and copy the memory content to fake a "duplicate" of the original
executable image. The problem is that when loading the executable file and
the shared libraries, they have to end up at the same positions, but cygwin
fails to do it properly and thus the copy that is produced cannot function.

This is solely a cygwin problem and we run into it because of the use of
fork(). We need it for ext:run-program, and all the functionality it
provides -- redirection of child's input/output/error channels, waiting for
processes, etc.

An alternative is to reuse the Windows code instead of fork+execve. I have
tried this today but there are other problems
- Almost all cygwin executables are symlinked in a way that is not open to
Windows, thus "gcc" is actually found through two symlinks that are internal
to cygwin, not expose to the operating system libraries.
- This would force us to code a function that searches the "PATH" for the
program we want to run.
- But things do not stop there, because when cygwin invokes a program it
does some massaging of the environment (PATH from posix to Windows syntax,
remapping other environment variables, mapping arguments to execve to the
right pathname convention...)

Overall the result needs quite some effort and looks more like a hack than
like a real solution, which is why I do not feel very motivated to implement
it...

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20110528/019cfbd5/attachment.html>