This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


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

Re: win32 popen clone for mingw32 anyone?


Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> writes:
> Mumit Khan <khan@xraylith.wisc.edu> writes:
> 
> 
> The original source of these problems was Guido's port of R, so you
> may want to pick up R-0.61.3 and his patches from a nearby CRAN site,
> e.g. http://cran.stat.wisc.edu/
>                                                  
> I suspect that the problem was that the resource file did an 
> 
> #include <windows.h> 
> 
> which kills windres at the 1st typedef (is that a bug, BTW?) - this
> happens when crosscompiling too. Then with the receiving end of the
> pipe dead, the pipe spills into stdout.

Oh that problem. I didn't read the description carefully enough last time.
Windres doesn't understand C/C++ specific constructs and should not be
expected to deal with it. Here's how standard includes should look like:
  
  /* essential/common defines needed for C/C++/resource files. */
  /* .... */

  #ifndef RC_INVOKED
  /* rest of C defs/decls that windres should never see */

  #endif /* RC_INVOKED */

In the headers distributed with egcs-1.0.2/mingw32, the system headers do
have this guard, and hence windres should never see the typedefs etc (and
hence shouldn't abort) after the preprocessor is done with it.

Perhaps the R folks are using an older version of egcs or mingw32 headers?

Here I'm referring to not being able to reproduce the bug where windres 
can't create resource because the output from CPP goes to the screen.

This is what happens:
  
  - windres calls the pre-processor via popen
    * if --preprocessor flag is given, then it uses that; otherwise,
    * use 'gcc -E -xc-header -DRC_INVOKED'
  - windres now reads from the file descriptor returned by popen. All
    output to stdout from the "popen'd" process should now go to this
    file descriptor, but it seems to go to the CONSOLE according to this
    bug.

I couldn't reproduce it using crtdll.dll version 3.50; I'd be happy 
provide others with my rewrite of Perl's popen/pclose routines to try 
out.

Note that in the case where the default preprocessor is used, there are
*two* levels of process creation -- windres calls gcc, and gcc calls cpp. 
I suggest folks who're having this problem try the following:
  
  % windres --preprocessor cpp --define RC_INVOKED -o testres.o test.rc

Before doing that, you'll have to add the directory containing cpp.exe to
your path (or copy cpp.exe to somewhere in your path). Also, please try
this on a trivial file with no extra includes to avoid adding lots of
--include arguments.

If this works, this will eliminate the popen from the culprit list and
point to Windows' bug in setting standard input/output descriptors when
creating new processes (possibly in one of the *spawn* routines).

Regards,
Mumit
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".


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