This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problem with pex-win32.c


Mark Mitchell wrote:
>The new pex-win32.c code doesn't operate correctly when used for
>MinGW-hosted tools invoked from a Cygwin window.  In particular, process
>creation ("gcc" invoking "as", say) results in a DOS console window
>popping up.  When invoked from a DOS window, things are fine.

What sort of "Cygwin window" are you talking about?  Cygwin bash running
in a normal Windows console window, or an rxvt or xterm window?

>The reason for this problem is that the current code uses MSVCRT's spawn
>to create the process, and that function doesn't provide fine enough
>control.  You have to use CreateProcess to make this work as desired.
>When invoking CreateProcess, you must set bInheritHandle to TRUE and
>pass a long a STARTUPINFO structure with dwFlags set to
>STARTF_USESTDHANDLES, and the various hStd* handle fields set to the
>values from the calling process. 

Setting bInheritHandle to TRUE causes the newly created process to
inherit all of its parent process's inheritable handles.  There's no
point in using the STARTUPINFO structure to specify handles for stdin,
stdout, and/or stderr unless you're changing them.  Since MSVCRT's spawn
sets bInheritHandle to TRUE, I don't see what difference this would make.

I think you're barking up the wrong tree here.  Windows only creates
console windows automagically when a console application starts that
can't inherit its parent's console window.  Either gcc is somehow losing
it's console window or it never had one to begin with.  Hmm... if that
"#!" kludge is being used here then it could be the shell that's losing
the console.

						Ross Ridge


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]