Hi everyone,<br><br>I have been tracking the cygwin issues along different fronts. My conclusions are not good, but I might be wrong.<br><br>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.<br>

<br>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.<br>

<br>An alternative is to reuse the Windows code instead of fork+execve. I have tried this today but there are other problems<br>- 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.<br>

- This would force us to code a function that searches the "PATH" for the program we want to run.<br>- 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...)<br>

<br>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...<br><br>Juanjo<br clear="all"><br>-- <br>Instituto de Física Fundamental, CSIC<br>

c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com" target="_blank">http://juanjose.garciaripoll.googlepages.com</a><br>