Re: [Mingw-msys] MSYS and Win98 Woes

[Paul G. <pgarceau@at...>]

On 9 Sep 2002 at 16:32, Ranjit Mathew wrote:

> Hi,
> 
>      I have a fundamental question: does MSYS work reliably
> at all on Win98?

	yes.

> Have any of you faced "weird"
> problems on Win98 that have not been there on WinNT/2K?

	Don't typically use Win2k, do use NT4.  Win98 always has problems that NT4 and 
Win2k (fwiw, aka NT5.2) do not.

	In terms of WinNT (NT4), no problems.  Been porting a lot of apps/packages under 
NT4 and have had very few and what problems have come up are mostly little problems 
with Msys which do not, for the most part,  impact completions of any of the ports I've been 
working on.

> (My Win2K boxes run on PIIIs, while the Win98 box runs on
> a PII - I have been using the "686" versions of MSYS
> 1.0.7 and 1.0.8-Snapshot.)

	Ok.  Latest release of 1.0.8 (dated 9/7/2002) is not 686 version, and so far has 
worked fine under Win9x after modification to Msys desktop shortcut has been made (see 
below).

> 
> I've been happily using MSYS on WinNT/2K for some time
> now, but Win98 gives me lots of completely arbitrary
> errors. For example, at one point "tar" extracted a file
> and switched the case of one of the letters in a source
> file, while it did not, when I repeated the "extract"!
> 
> "tar" also gives me "Child process died with error" errors
> once in approximately three runs of a
> "tar -tzvf w32api-2.0.tgz".

	Don't know what causes this last.  Have heard rumors that PID may be getting 
maxed out under MSys.  Since they are only rumors, I do not put much trust in them.

> 
> I'm able to build GCC3.2 perfectly well on Win2K, but not
> on Win98 - it dies out in the bootstrap stage itself, with
> xgcc not being able to locate the standard headers like
> stdio.h, time.h, etc. (Yes, I *have* specified both the
> --prefix and --oldincludedir options to the GCC configure.)

	When you installed (assuming you are talking about Win98) Msys, without knowing 
about the workaround noted below, the process responsible for creating the necessary 
mount points for Mingw (assuming of course you are using gcc included as part of Mingw-
1.1) did not complete.

	Therefore, whenever the GCC3.2 build is attempted, it will not be able to find the 
headers noted above.

	Problem has very little to do with --prefix and/or --oldincludedir options being 
enabled or not within gcc configure.

	Configure typically makes certain assumptions based on data files added during 
Msys install process (see "etc/fstab" or "usr/etc/fstab").  If etc/fstab does not exist then there 
is no way that Msys can know where your Mingw distribution is installed...

> 
> BTW, the MSYS installer also failed in the "pi.bat"
> postinstall script with an "Out of Environment Space"
> error.

	This last is a known error.

	Until a fix is included with the install, here is a suggestion/workaround for Win9x:

	right click on Msys icon, select properties
	
	In cmd line box replace "D:\MSYS\1.0\MSYS.BAT"

	with

	"c:\windows\command.com /E:4096 /c D:\MSYS\1.0\MSYS.BAT"

	This sets the environment space to 4096 (4k) and launches MSYS.BAT within 
command.com shell.  This is also the way Cygwin launches Cygwin.bat.  Msys is a "fork" of 
Cygwin.

	NT4, as a counterpoint, automatically launches any .bat file under cmd.com 
(NTVDM).  Win2k does, more or less, the same thing.

	Paul G.

[Mingw-msys] MSYS and Win98 Woes

[Ranjit Mathew <rmathew@ho...>]

Hi,

     I have a fundamental question: does MSYS work reliably
at all on Win98? Have any of you faced "weird"
problems on Win98 that have not been there on WinNT/2K?
(My Win2K boxes run on PIIIs, while the Win98 box runs on
a PII - I have been using the "686" versions of MSYS
1.0.7 and 1.0.8-Snapshot.)

I've been happily using MSYS on WinNT/2K for some time
now, but Win98 gives me lots of completely arbitrary
errors. For example, at one point "tar" extracted a file
and switched the case of one of the letters in a source
file, while it did not, when I repeated the "extract"!

"tar" also gives me "Child process died with error" errors
once in approximately three runs of a
"tar -tzvf w32api-2.0.tgz".

I'm able to build GCC3.2 perfectly well on Win2K, but not
on Win98 - it dies out in the bootstrap stage itself, with
xgcc not being able to locate the standard headers like
stdio.h, time.h, etc. (Yes, I *have* specified both the
--prefix and --oldincludedir options to the GCC configure.)

BTW, the MSYS installer also failed in the "pi.bat"
postinstall script with an "Out of Environment Space"
error.

:-(

Ranjit.

Re: [Mingw-msys] MSYS and Win98 Woes

[Paul G. <pgarceau@at...>]

On 9 Sep 2002 at 16:32, Ranjit Mathew wrote:

> Hi,
> 
>      I have a fundamental question: does MSYS work reliably
> at all on Win98?

	yes.

> Have any of you faced "weird"
> problems on Win98 that have not been there on WinNT/2K?

	Don't typically use Win2k, do use NT4.  Win98 always has problems that NT4 and 
Win2k (fwiw, aka NT5.2) do not.

	In terms of WinNT (NT4), no problems.  Been porting a lot of apps/packages under 
NT4 and have had very few and what problems have come up are mostly little problems 
with Msys which do not, for the most part,  impact completions of any of the ports I've been 
working on.

> (My Win2K boxes run on PIIIs, while the Win98 box runs on
> a PII - I have been using the "686" versions of MSYS
> 1.0.7 and 1.0.8-Snapshot.)

	Ok.  Latest release of 1.0.8 (dated 9/7/2002) is not 686 version, and so far has 
worked fine under Win9x after modification to Msys desktop shortcut has been made (see 
below).

> 
> I've been happily using MSYS on WinNT/2K for some time
> now, but Win98 gives me lots of completely arbitrary
> errors. For example, at one point "tar" extracted a file
> and switched the case of one of the letters in a source
> file, while it did not, when I repeated the "extract"!
> 
> "tar" also gives me "Child process died with error" errors
> once in approximately three runs of a
> "tar -tzvf w32api-2.0.tgz".

	Don't know what causes this last.  Have heard rumors that PID may be getting 
maxed out under MSys.  Since they are only rumors, I do not put much trust in them.

> 
> I'm able to build GCC3.2 perfectly well on Win2K, but not
> on Win98 - it dies out in the bootstrap stage itself, with
> xgcc not being able to locate the standard headers like
> stdio.h, time.h, etc. (Yes, I *have* specified both the
> --prefix and --oldincludedir options to the GCC configure.)

	When you installed (assuming you are talking about Win98) Msys, without knowing 
about the workaround noted below, the process responsible for creating the necessary 
mount points for Mingw (assuming of course you are using gcc included as part of Mingw-
1.1) did not complete.

	Therefore, whenever the GCC3.2 build is attempted, it will not be able to find the 
headers noted above.

	Problem has very little to do with --prefix and/or --oldincludedir options being 
enabled or not within gcc configure.

	Configure typically makes certain assumptions based on data files added during 
Msys install process (see "etc/fstab" or "usr/etc/fstab").  If etc/fstab does not exist then there 
is no way that Msys can know where your Mingw distribution is installed...

> 
> BTW, the MSYS installer also failed in the "pi.bat"
> postinstall script with an "Out of Environment Space"
> error.

	This last is a known error.

	Until a fix is included with the install, here is a suggestion/workaround for Win9x:

	right click on Msys icon, select properties
	
	In cmd line box replace "D:\MSYS\1.0\MSYS.BAT"

	with

	"c:\windows\command.com /E:4096 /c D:\MSYS\1.0\MSYS.BAT"

	This sets the environment space to 4096 (4k) and launches MSYS.BAT within 
command.com shell.  This is also the way Cygwin launches Cygwin.bat.  Msys is a "fork" of 
Cygwin.

	NT4, as a counterpoint, automatically launches any .bat file under cmd.com 
(NTVDM).  Win2k does, more or less, the same thing.

	Paul G.

[Mingw-msys] Re: MSYS and Win98 Woes

[Ranjit Mathew <rmathew@ho...>]

Paul G. wrote:
> 
>>"tar" also gives me "Child process died with error" errors
>>once in approximately three runs of a
>>"tar -tzvf w32api-2.0.tgz".
> 
> 
> 	Don't know what causes this last.  Have heard rumors that PID may be getting 
> maxed out under MSys.  Since they are only rumors, I do not put much trust in them.

I also have a Win32 native tar that has *no such problems*, while
the MSYS tar gives a:

     tar: Child died with signal 13
     tar: Error exit delayed from previous errors

on "w32api-2.0.tar.gz" 1 out of 3 times (on Win98 as well as
on Win2K) - I invite you to try it out yourself.

As for maxing out on process creation, since MSYS is a fork
of Cygwin, you might want to check out:

     http://cygwin.com/cygwin-ug-net/highlights.html

Specifically, the following bits:
------------------------------ 8< ------------------------------------
The fork call in Cygwin is particularly interesting because it does not 
map well on top of the Win32 API. This makes it very difficult to 
implement correctly. Currently, the Cygwin fork is a non-copy-on-write 
implementation similar to what was present in early flavors of UNIX.

The first thing that happens when a parent process forks a child process 
is that the parent initializes a space in the Cygwin process table for 
the child. It then creates a suspended child process using the Win32 
CreateProcess call. Next, the parent process calls setjmp to save its 
own context and sets a pointer to this in a Cygwin shared memory area 
(shared among all Cygwin tasks). It then fills in the child's .data and 
.bss sections by copying from its own address space into the suspended 
child's address space. After the child's address space is initialized, 
the child is run while the parent waits on a mutex. The child discovers 
it has been forked and longjumps using the saved jump buffer. The child 
then sets the mutex the parent is waiting on and blocks on another 
mutex. This is the signal for the parent to copy its stack and heap into 
the child, after which it releases the mutex the child is waiting on and 
returns from the fork call. Finally, the child wakes from blocking on 
the last mutex, recreates any memory-mapped areas passed to it via the 
shared area, and returns from fork itself.
------------------------------ 8< ------------------------------------

These kludges *could* be a cause for most of the problems, but I
really don't know.

I'm going completely nuts trying to figure out why identical
GCC configuration and build scripts behave completely differently
on Win2K and Win98 - I have reinstalled MinGW/MSYS to ensure that
they are the same, I have checked the /etc/fstab file (identical)
and yet, every time the GCC build on Win98 fails to find the
standard include files like stdio.h, time.h after building
the stage one compiler (i.e. while using the stage 1 xgcc compiler
to build the stage 2 compiler). This happens *consistently*
on Windows - the command line passed by make to the xgcc
compiler also looks exactly the same - what in the heavens
*could* be wrong?

:-(

Absolutely any help in this matter is most welcome!

Ranjit.

Re: [Mingw-msys] Re: MSYS and Win98 Woes

[Earnie Boyd <earnie_boyd@ya...>]

Ranjit Mathew wrote:
> 
> on Windows - the command line passed by make to the xgcc
> compiler also looks exactly the same - what in the heavens
> *could* be wrong?
> 

Is it environment space issue?  Is it number of files and or channels
open issue?  Win98 is really a DOS while W2K is a Win32 OS.

Earnie.

[Mingw-msys] Re: MSYS and Win98 Woes

[Ranjit Mathew <rmathew@ho...>]

Earnie Boyd wrote:
> Ranjit Mathew wrote:
> 
>>on Windows - the command line passed by make to the xgcc
>>compiler also looks exactly the same - what in the heavens
>>*could* be wrong?
>>
> 
> 
> Is it environment space issue?  Is it number of files and or channels
> open issue?  Win98 is really a DOS while W2K is a Win32 OS.

Well, when I changed the "--prefix=/mingw" option to the GCC configure
to "--prefix=d:/MinGW" things got going. Duh!

This looks reasonable considering that only the MSYS-native programs
should be able to understand the mounted paths and not "normal" Win32
applications built using GCC.

However, why does it work on Win2K then?

Ranjit.

Re: [Mingw-msys] Re: MSYS and Win98 Woes

[Earnie Boyd <earnie_boyd@ya...>]

Ranjit Mathew wrote:
> 
> However, why does it work on Win2K then?
> 

Hmm...  I haven't a clue what the difference might be.  Are you sure you
have the same MSYS version on both?  This just points to my needing to
find a nice Win98 machine for testing.

Earnie.

[Mingw-msys] Re: MSYS and Win98 Woes

[Ranjit Mathew <rmathew@ho...>]

Hi,

     Here's a completely baffling (to me) twist: the
following program *should not* work on Win2K but it
does! It does fail on my Win98SE box though as
expected. Can some one please try this out and
confirm this?

FYI, here's my configuration (on the Win2K/SP2 box):
----------------------- 8< --------------------------
/c/tmp > gcc --version
gcc.exe (GCC) 3.2 (mingw special 20020817-1)

/c/tmp > uname -a
MINGW32_NT-5.0 REPORT-GEN 1.0.8(0.46/3/2) 2002-09-07 16:04 i686 unknown

/c/tmp > ld -v
GNU ld version 2.13

(and mingw-runtime 2.2 with w32api 2.0)
----------------------- 8< --------------------------

And here's the C program that tries to print out the
first 255 characters of "/mingw/include/stdio.h" - it
should have failed since it is not an MSYS-native
program but it actually works!
----------------------- 8< --------------------------
#include <stdio.h>

int main( void)
{
     FILE *fp = fopen( "/mingw/include/stdio.h", "r");

     if( fp == NULL)
     {
         printf( "This is as things should be!\n");
     }
     else
     {
         char buff[256];

         fread( buff, 1, sizeof( buff) - 1, fp);
         buff[255] = '\0';
         printf( "%s\n", buff);
     }

     return 0;
}
----------------------- 8< --------------------------

And here's the output I get on my Win2K box:
----------------------- 8< --------------------------
/*
  * stdio.h
  *
  * Definitions of types and prototypes of functions for standard input and
  * output.
  *
  * NOTE: The file manipulation functions provided by Microsoft seem to
  * work with either slash (/) or backslash (\) as the path separator.
  *
  * Th
----------------------- 8< --------------------------

Is there something blindingly obvious that I'm missing?

Ranjit.

Earnie Boyd wrote:
> Ranjit Mathew wrote:
> 
>>However, why does it work on Win2K then?
>>
> 
> 
> Hmm...  I haven't a clue what the difference might be.  Are you sure you
> have the same MSYS version on both?  This just points to my needing to
> find a nice Win98 machine for testing.
> 
> Earnie.
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf