mingw-msys Mailing List for MinGW - Minimalist GNU for Windows

Hi Earnie.

I have had three (out of three) MSYS 1.08 sessions left running overnight
die during the night as documented below by the famous Dr Mingw.

Cheers

Mike Thomas.

---------------------------------------------------------------------------
rxvt.exe caused an Access Violation at location 71044d8c in module
msys-1.0.dll Writing to location 00000000.

Registers:
eax=00000000 ebx=00000008 ecx=00000002 edx=00000001 esi=00000000
edi=00000008
eip=71044d8c esp=1a25f93c ebp=1a25fa88 iopl=0         nv up ei pl zr na po
nc
cs=001b  ss=0023  ds=0023  es=0023  fs=0038  gs=0000
efl=00000246

Call stack:
71044D8C  msys-1.0.dll:71044D8C  cygwin32_posix_to_win32_path_list
710450C8  msys-1.0.dll:710450C8  cygwin32_posix_to_win32_path_list
710455FB  msys-1.0.dll:710455FB  cygwin_winpid_to_pid
71045599  msys-1.0.dll:71045599  cygwin_winpid_to_pid
71059E06  msys-1.0.dll:71059E06  _sigprocmask
7100497A  msys-1.0.dll:7100497A  _dll_crt0@0
7100FC7F  msys-1.0.dll:7100FC7F  strerror
7100FB3D  msys-1.0.dll:7100FB3D  strerror
7105D029  msys-1.0.dll:7105D029  pause
710052C2  msys-1.0.dll:710052C2  _exit
77E8758A  KERNEL32.dll:77E8758A  SetFilePointer

> Joshua Nekl wrote:
> 
> If anyone has a clue what's going on, I'd appreciate a hint. I'm
> >guessing< that some of these utilities may have been linked with a
> different C runtime library, one that passes stdout through some kind
> of filter which remaps the ESC sequences to whatever M$ wants if the
> output isatty()/console.
> 

Yes, it's the msys-1.0.dll.  The source is available via CVS.  See
http://sf.net/projects/mingw and the CVS menu option.

Earnie.

I'm trying to write a terminal/console mode program that uses colors. A =
simple example:

#include    <stdio.h>

int main(void)
{
    printf("\033[32mHello World\033[39m\n");
    return 0;
}

This works perfectly on unix systems as the way most color xterms =
support colors is by using ansi escape sequences. This also works with =
rxvt that comes with the msys environment. Thing is, it will not work in =
a normal dos box. The escape character \033 gets printed as an graphics =
character and the [33m appears as regular text.=20

Now the 'ls --color' works properly in a dos box, so I know it is =
possiable to do this in a regular dos box. As a matter of fact, if I run =
the following in a dos box, the output of my program appears in color =
just fine.

    test | cat

I've even tried redirecting the output from the cat to a file to see =
exactly what's is being output

    test | cat > catoutput.txt
    test > testoutput.txt

Both are identical ??? If I cat either one, they both appear in color. =
If I issue 'type output.txt', the escape sequence appears as normal text =
and I get no color. I've done the same with the output from 'ls --color' =
with the same results.

Now I've tried looking at the source for ls.c and couldn't see anything =
special. They just did a simple putchar(ESC SEQUENCE). Compiled the =
textutils cat that comes with msys-1.0.7. When I ran it on my previous =
output files, the output was no longer in color ??? I am using =
msys-1.0.8 though. Couldn't find the src download for it, and when I =
grabbed the latest CVS sources, textutils wasn't in there???

If anyone has a clue what's going on, I'd appreciate a hint. I'm =
>guessing< that some of these utilities may have been linked with a =
different C runtime library, one that passes stdout through some kind of =
filter which remaps the ESC sequences to whatever M$ wants if the output =
isatty()/console.

Josh

Mo DeJong wrote:
> 
> Hello.
> 
> I have noticed that the AC_PROG_MAKE_SET from autoconf (2.13 or 2.5X) does
> not interact well with msys-1.0.8-i386-2002.06.25 under Windows 98. Here
> is the output I see when running a generated configure script.
> 
> checking whether make sets ${MAKE}... ../../tk/win/configure: eval: line 1: unexpected EOF while looking for matching `"'
> ../../tk/win/configure: eval: line 2: syntax error: unexpected end of file
> no
> 
> This does not appear to break anything, but it sure seems like a bug in msys.
> I can run this same ./configure script with Cygwin and it works just fine.
> Is this a known problem, or should I file a new bug report for it?
> 

Consider the bug report filed for this version.  It may be taken care of
already.

Earnie.

Yes. I bet that's it.

Paul Butcher wrote:
> I forgot to say I'm using the gcc3.1 from MinGW.  I replaced the libobjc.a 
> file in the gcc path with the GNUstep one I compiled as per the README.MinGW 
> instructions.  
> I note that libgnustep-base.def file in the GNUstep distribution contains 
> `__objc_class_name_NXConstantString' as a required DLL export - is this what 
> is causing the problem?
> 
> On Tuesday 23 Jul 2002 15:31, Adam Fedor wrote:
> 
>>What gcc version are you using? In 3.x, NXConstantString is replaced
>>internally (in GNUstep) by NSConstantString. If it's looking for
>>NXConstantString it probably indicates a problem in the configuration,
>>or perhaps there is an old version of the libobjc library laying around
>>(from a previous gcc or GNUstep installation).
>>
>>Paul Butcher wrote:
>>
>>>As per a previous mailing I am trying to carefully follow the
>>>instructions in README.MinGW on building GNUstep under MinGW/msys for
>>>win32.
>>>
>>>I have got through to building GNUstep-base now and get this error
>>>message at the final linking of the gnustep-base DLL:
>>> gnustep-base.exp(.edata+0x7a8):fake: undefined reference to
>>>`__objc_class_name_NXConstantString'
>>>f:\mingw\bin\dllwrap.exe: gcc exited with status 1
>>>make[2]: *** [shared_obj/ix86/mingw32/gnu-gnu-gnu/gnustep-base.dll] Error
>>>1 make[1]: *** [libgnustep-base.all.library.variables] Error 2
>>>make[1]: Leaving directory `/tmp/gnustep-base-1.3.4/Source'
>>>make: *** [internal-all] Error 2
>>>
>>>As I understand it, NXConstantString is excluded from the GNUstep objc
>>>library and reimiplemented in GSString.m.  If I use objdump to look at
>>>symbols defined in GSString.o I find that NXConstantString is not there -
>>>but instead NSConstantString.  I am puzzled how a class implemented in
>>>the source code does not appear in the compiled code??
>>
> 
> 
> Paul Butcher
> Alton, Hants, UK
> 



-- 
Adam Fedor, Digital Optics Corp.      | I'm glad I hate spinach, because
http://www.doc.com                    | if I didn't, I'd eat it, and you
                                       | know how I hate the stuff.

I forgot to say I'm using the gcc3.1 from MinGW.  I replaced the libobjc.a 
file in the gcc path with the GNUstep one I compiled as per the README.MinGW 
instructions.  
I note that libgnustep-base.def file in the GNUstep distribution contains 
`__objc_class_name_NXConstantString' as a required DLL export - is this what 
is causing the problem?

On Tuesday 23 Jul 2002 15:31, Adam Fedor wrote:
>
> What gcc version are you using? In 3.x, NXConstantString is replaced
> internally (in GNUstep) by NSConstantString. If it's looking for
> NXConstantString it probably indicates a problem in the configuration,
> or perhaps there is an old version of the libobjc library laying around
> (from a previous gcc or GNUstep installation).
>
> Paul Butcher wrote:
> > As per a previous mailing I am trying to carefully follow the
> > instructions in README.MinGW on building GNUstep under MinGW/msys for
> > win32.
> >
> > I have got through to building GNUstep-base now and get this error
> > message at the final linking of the gnustep-base DLL:
> >  gnustep-base.exp(.edata+0x7a8):fake: undefined reference to
> > `__objc_class_name_NXConstantString'
> > f:\mingw\bin\dllwrap.exe: gcc exited with status 1
> > make[2]: *** [shared_obj/ix86/mingw32/gnu-gnu-gnu/gnustep-base.dll] Error
> > 1 make[1]: *** [libgnustep-base.all.library.variables] Error 2
> > make[1]: Leaving directory `/tmp/gnustep-base-1.3.4/Source'
> > make: *** [internal-all] Error 2
> >
> > As I understand it, NXConstantString is excluded from the GNUstep objc
> > library and reimiplemented in GSString.m.  If I use objdump to look at
> > symbols defined in GSString.o I find that NXConstantString is not there -
> > but instead NSConstantString.  I am puzzled how a class implemented in
> > the source code does not appear in the compiled code??


Paul Butcher
Alton, Hants, UK

What gcc version are you using? In 3.x, NXConstantString is replaced 
internally (in GNUstep) by NSConstantString. If it's looking for 
NXConstantString it probably indicates a problem in the configuration, 
or perhaps there is an old version of the libobjc library laying around 
(from a previous gcc or GNUstep installation).

Paul Butcher wrote:
> As per a previous mailing I am trying to carefully follow the instructions in 
> README.MinGW on building GNUstep under MinGW/msys for win32.
> 
> I have got through to building GNUstep-base now and get this error message at 
> the final linking of the gnustep-base DLL:
>  gnustep-base.exp(.edata+0x7a8):fake: undefined reference to 
> `__objc_class_name_NXConstantString'
> f:\mingw\bin\dllwrap.exe: gcc exited with status 1
> make[2]: *** [shared_obj/ix86/mingw32/gnu-gnu-gnu/gnustep-base.dll] Error 1
> make[1]: *** [libgnustep-base.all.library.variables] Error 2
> make[1]: Leaving directory `/tmp/gnustep-base-1.3.4/Source'
> make: *** [internal-all] Error 2
> 
> As I understand it, NXConstantString is excluded from the GNUstep objc 
> library and reimiplemented in GSString.m.  If I use objdump to look at 
> symbols defined in GSString.o I find that NXConstantString is not there - but 
> instead NSConstantString.  I am puzzled how a class implemented in the source 
> code does not appear in the compiled code??
> 
> 
> Paul Butcher
> Alton, Hants, UK



-- 
Adam Fedor, Digital Optics Corp.      | I'm glad I hate spinach, because
http://www.doc.com                    | if I didn't, I'd eat it, and you
                                       | know how I hate the stuff.

Hello.

I have noticed that the AC_PROG_MAKE_SET from autoconf (2.13 or 2.5X) does
not interact well with msys-1.0.8-i386-2002.06.25 under Windows 98. Here
is the output I see when running a generated configure script.

checking whether make sets ${MAKE}... ../../tk/win/configure: eval: line 1: unexpected EOF while looking for matching `"'
../../tk/win/configure: eval: line 2: syntax error: unexpected end of file
no

This does not appear to break anything, but it sure seems like a bug in msys.
I can run this same ./configure script with Cygwin and it works just fine.
Is this a known problem, or should I file a new bug report for it?

Mo

As per a previous mailing I am trying to carefully follow the instructions in 
README.MinGW on building GNUstep under MinGW/msys for win32.

I have got through to building GNUstep-base now and get this error message at 
the final linking of the gnustep-base DLL:
 gnustep-base.exp(.edata+0x7a8):fake: undefined reference to 
`__objc_class_name_NXConstantString'
f:\mingw\bin\dllwrap.exe: gcc exited with status 1
make[2]: *** [shared_obj/ix86/mingw32/gnu-gnu-gnu/gnustep-base.dll] Error 1
make[1]: *** [libgnustep-base.all.library.variables] Error 2
make[1]: Leaving directory `/tmp/gnustep-base-1.3.4/Source'
make: *** [internal-all] Error 2

As I understand it, NXConstantString is excluded from the GNUstep objc 
library and reimiplemented in GSString.m.  If I use objdump to look at 
symbols defined in GSString.o I find that NXConstantString is not there - but 
instead NSConstantString.  I am puzzled how a class implemented in the source 
code does not appear in the compiled code??


Paul Butcher
Alton, Hants, UK

Paul Butcher wrote:
> 
> On Thursday 18 Jul 2002 13:41, Earnie Boyd wrote:
> >
> > Hmm...  How is the path name formed within the script?  I will note that
> > the /tmp path is a mount point to the value of the TMP windows
> > environment variable.  Do you have a TEMP windows environment variable
> > set?  If so, what is the value?
> 
> TEMP is set same as TMP in autoexec.bat.
> 
> However ... looking through the configure script in more detail I note that
> temporary files are written to /tmp, which as you say is mounted by msys to
> windows TMP directory.  It is then trying to call 'mktemp' to form a unique
> temp directory name - due to my path it's possible this picked up the cygwin
> 'mktemp' which may have returned the incorrect format path to msys 'sed'.  I
> will check this out later when back on my Windows machine.
> 

If it is as you say and mktemp from Cygwin was used then the /tmp would
most likely have been converted to the Win32 native path.  My
documentation for MSYS warns you to remove Cygwin from the PATH.

Earnie.

On Thursday 18 Jul 2002 13:41, Earnie Boyd wrote:
>
> Paul Butcher wrote:
> > I'm carefully following the README.MinGW instructions on building GNUstep
> > with MinGW and MSYS V1.0.7.  I have the following problem running the
> > configure script of gnustep-make from within msys 'sh':
> >
> > when trying to write each of the files at end of configure (eg
> > config.make, openapp, debugapp, opentool....) the following pair of
> > errors occur:
> >
> > sed: couldn't open file G:TEMPcs422235/subs-1.sed
> > sed: couldn't open file G:TEMPcs422235/subs-2.sed
> >
> > it seems my TMP DOS environment variable (set to G:\TEMP) is being used
> > for tmp directory and the backslashes are taken away by sh - what is the
> > solution??
>
> Hmm...  How is the path name formed within the script?  I will note that
> the /tmp path is a mount point to the value of the TMP windows
> environment variable.  Do you have a TEMP windows environment variable
> set?  If so, what is the value?

TEMP is set same as TMP in autoexec.bat.

However ... looking through the configure script in more detail I note that 
temporary files are written to /tmp, which as you say is mounted by msys to 
windows TMP directory.  It is then trying to call 'mktemp' to form a unique 
temp directory name - due to my path it's possible this picked up the cygwin 
'mktemp' which may have returned the incorrect format path to msys 'sed'.  I 
will check this out later when back on my Windows machine.

Thanks both for offering help.

Paul Butcher
Alton, Hants, UK

Paul Butcher wrote:
> 
> I'm carefully following the README.MinGW instructions on building GNUstep
> with MinGW and MSYS V1.0.7.  I have the following problem running the
> configure script of gnustep-make from within msys 'sh':
> 
> when trying to write each of the files at end of configure (eg config.make,
> openapp, debugapp, opentool....) the following pair of errors occur:
> 
> sed: couldn't open file G:TEMPcs422235/subs-1.sed
> sed: couldn't open file G:TEMPcs422235/subs-2.sed
> 
> it seems my TMP DOS environment variable (set to G:\TEMP) is being used for
> tmp directory and the backslashes are taken away by sh - what is the
> solution??
> 

Hmm...  How is the path name formed within the script?  I will note that
the /tmp path is a mount point to the value of the TMP windows
environment variable.  Do you have a TEMP windows environment variable
set?  If so, what is the value?

Earnie.

I'm carefully following the README.MinGW instructions on building GNUstep 
with MinGW and MSYS V1.0.7.  I have the following problem running the 
configure script of gnustep-make from within msys 'sh':

when trying to write each of the files at end of configure (eg config.make, 
openapp, debugapp, opentool....) the following pair of errors occur:

sed: couldn't open file G:TEMPcs422235/subs-1.sed
sed: couldn't open file G:TEMPcs422235/subs-2.sed

it seems my TMP DOS environment variable (set to G:\TEMP) is being used for 
tmp directory and the backslashes are taken away by sh - what is the 
solution??

Paul Butcher
Alton, Hants, UK

Luke Dunstan wrote:
> 
> ----- Original Message -----
> From: "Earnie Boyd" <ear...@ya...>
> To: "Elizabeth Barham" <sog...@ya...>
> Cc: <min...@li...>
> Sent: Wednesday, July 17, 2002 12:51 AM
> Subject: Re: [Mingw-msys] Forking Error
> 
> > Which version of MSYS (the output of `uname -a')?
> >
> > This is the first report of this so, I'm not sure what is your problem.
> 
> First report?
> 
> http://sourceforge.net/mailarchive/message.php?msg_id=1439294
> 
> :)
> 

Sorry, Luke, I didn't remember that one.  O.K. I'll upload, before the
end of the week, a new snapshot.  I was almost ready to do that today,
but I just discovered a bug that needs squashed.

Earnie.

"Luke Dunstan" <cod...@ho...> writes:
>
> <http://sourceforge.net/mailarchive/message.php?msg_id=1439294>
>
>> Also, I did not have this problem on a different computer running
>> Windows 2000, though that system also has more memory...

Sounds Win98 specific.

Elizabeth

Earnie Boyd <ear...@ya...> writes:

> Curious, how much physical memory do you have?

384 M

> Also, curious, what happens if you remove rxvt.exe from the process
> tree. To test:
> 1) Exit all MSYS processes.
> 2) Use the Windows file manager to rename \msys\1.0\bin\rxvt.exe to
>    rxvt.exe.bak
> 3) Click on the MSYS icon, this will start MSYS in a command.com
>    window.
> 4) execute your configure script.

It errored around the same place.

Elizabeth

----- Original Message -----
From: "Earnie Boyd" <ear...@ya...>
To: "Elizabeth Barham" <sog...@ya...>
Cc: <min...@li...>
Sent: Wednesday, July 17, 2002 12:51 AM
Subject: Re: [Mingw-msys] Forking Error


> Which version of MSYS (the output of `uname -a')?
>
> This is the first report of this so, I'm not sure what is your problem.

First report?

http://sourceforge.net/mailarchive/message.php?msg_id=1439294

:)

> I'll try to take a look into it.
>
> Earnie.
>
> Elizabeth Barham wrote:
> >
> > Hi Earnie, everyone,
> >
> > I'm very new to msys and am currently trying to use it for compiling
> > ImageMagick. During ./configure, though, my system gives me an error:
> >
> > $ ./configure
> > [ ... ]
> > configure: creating libtool
> > [ ... ]
> > checking for string.h... (cached) yes
> > checking stdarg.h usability... yes
> > checking stdarg.h presence...       0 [main] sh 509779 fork_copy:
user/cygwin data pass 2 failed, 0x9E0000..0xA95000, done 0, windows pid
4294482929, Win32 error 8
> > ./configure: fork: Resource temporarily unavailable
> > 2124109 [main] sh 509779 fork_copy: user/cygwin data pass 2 failed,
0x9E0000..0xA95000, done 0, windows pid 4294482177, Win32 error 8
> > ./configure: fork: Resource temporarily unavailable
> > 4398999 [main] sh 509779 fork_copy: user/cygwin data pass 2 failed,
0x9E0000..0xA95000, done 0, windows pid 4294443697, Win32 error 8
> > ./configure: fork: Resource temporarily unavailable
> > 6903956 [main] sh 509779 fork_copy: user/cygwin data pass 2 failed,
0x9E0000..0xA95000, done 0, windows pid 4294481317, Win32 error 8
> > ./configure: fork: Resource temporarily unavailable
> >
> > This ocurrs during the 'second pass' of configure as it had all ready
> > checked string.h earlier. The OS I'm using is Windows 98.
> >
> > Is there some setting I can use to make this resource available?
> >
> > Thank you, Elizabeth

Greg Chicares wrote:
> 
>   http://list-archive.xemacs.org/xemacs/200202/msg00003.html
> 

Well, I don't remember if I removed the registry read for
heap_chunk_in_mb.  If I didn't that might work.  If I did, you can set
it all you want and it won't help.  I'll check the code, the default for
1.0.7 is 4 MB.  The default for the current 1.0.8 snapshot is 6 MB but
I'm likely to change that back.

Earnie.

Elizabeth Barham wrote:
> 
> Elizabeth Barham <sog...@ya...> writes:
> 
> > Thank you. I'm going to try Bob's suggestion of increasing the size of
> > the swap file next.
> 
> Hi. I adjusted the virtual memory setting to 300 Megabytes as opposed
> to letting Win32 do it itself. The same error was thrown but earlier
> in ./configure so apparently it is a memory problem (doing a fresh
> ./configure caused the error to occur later). ./configure for slang
> worked mostly without a hitch (my mother has her username set with
> spaces in it which threw off dirname).
> 

Curious, how much physical memory do you have?  Also, curious, what
happens if you remove rxvt.exe from the process tree.  To test:
1) Exit all MSYS processes.
2) Use the Windows file manager to rename \msys\1.0\bin\rxvt.exe to
rxvt.exe.bak
3) Click on the MSYS icon, this will start MSYS in a command.com window.
4) execute your configure script.

> Oh well. Thank you for your wonderful product!
> 

Thanks, I'll see what I can do for you.

Earnie.

Elizabeth Barham wrote:
> 
> checking stdarg.h presence...       0 [main] sh 509779 fork_copy: user/cygwin data pass 2 failed, 0x9E0000..0xA95000, done 0, windows pid 4294482929, Win32 error 8
> ./configure: fork: Resource temporarily unavailable

Oddly enough, today someone reported an apparently similar
problem on a different mailing list:

  http://mail.gnu.org/pipermail/make-w32/2002-July/000164.html

Perhaps this message will be more helpful for solving the problem:

  http://list-archive.xemacs.org/xemacs/200202/msg00003.html

Elizabeth Barham <sog...@ya...> writes:

> Thank you. I'm going to try Bob's suggestion of increasing the size of
> the swap file next.

Hi. I adjusted the virtual memory setting to 300 Megabytes as opposed
to letting Win32 do it itself. The same error was thrown but earlier
in ./configure so apparently it is a memory problem (doing a fresh
./configure caused the error to occur later). ./configure for slang
worked mostly without a hitch (my mother has her username set with
spaces in it which threw off dirname).

Oh well. Thank you for your wonderful product!

Elizabeth

Hi Earnie,

Earnie Boyd <ear...@ya...> writes:

> Which version of MSYS (the output of `uname -a')?

MINGW32_98-4.10 LEONARDO 1.0.7(0.46/3/2) 2002-05-09 08:27 i686 unknown

> This is the first report of this so, I'm not sure what is your
> problem.  I'll try to take a look into it.

Thank you. I'm going to try Bob's suggestion of increasing the size of
the swap file next.

Kind regards, Elizabeth

Which version of MSYS (the output of `uname -a')?

This is the first report of this so, I'm not sure what is your problem. 
I'll try to take a look into it.

Earnie.

Elizabeth Barham wrote:
> 
> Hi Earnie, everyone,
> 
> I'm very new to msys and am currently trying to use it for compiling
> ImageMagick. During ./configure, though, my system gives me an error:
> 
> $ ./configure
> [ ... ]
> configure: creating libtool
> [ ... ]
> checking for string.h... (cached) yes
> checking stdarg.h usability... yes
> checking stdarg.h presence...       0 [main] sh 509779 fork_copy: user/cygwin data pass 2 failed, 0x9E0000..0xA95000, done 0, windows pid 4294482929, Win32 error 8
> ./configure: fork: Resource temporarily unavailable
> 2124109 [main] sh 509779 fork_copy: user/cygwin data pass 2 failed, 0x9E0000..0xA95000, done 0, windows pid 4294482177, Win32 error 8
> ./configure: fork: Resource temporarily unavailable
> 4398999 [main] sh 509779 fork_copy: user/cygwin data pass 2 failed, 0x9E0000..0xA95000, done 0, windows pid 4294443697, Win32 error 8
> ./configure: fork: Resource temporarily unavailable
> 6903956 [main] sh 509779 fork_copy: user/cygwin data pass 2 failed, 0x9E0000..0xA95000, done 0, windows pid 4294481317, Win32 error 8
> ./configure: fork: Resource temporarily unavailable
> 
> This ocurrs during the 'second pass' of configure as it had all ready
> checked string.h earlier. The OS I'm using is Windows 98.
> 
> Is there some setting I can use to make this resource available?
> 
> Thank you, Elizabeth
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: Jabber - The world's fastest growing
> real-time communications platform! Don't just IM. Build it in!
> http://www.jabber.com/osdn/xim
> _______________________________________________
> Mingw-msys mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-msys

Hi Earnie, everyone,

I'm very new to msys and am currently trying to use it for compiling
ImageMagick. During ./configure, though, my system gives me an error:

$ ./configure
[ ... ]
configure: creating libtool
[ ... ]
checking for string.h... (cached) yes
checking stdarg.h usability... yes
checking stdarg.h presence...       0 [main] sh 509779 fork_copy: user/cygwin data pass 2 failed, 0x9E0000..0xA95000, done 0, windows pid 4294482929, Win32 error 8
./configure: fork: Resource temporarily unavailable
2124109 [main] sh 509779 fork_copy: user/cygwin data pass 2 failed, 0x9E0000..0xA95000, done 0, windows pid 4294482177, Win32 error 8
./configure: fork: Resource temporarily unavailable
4398999 [main] sh 509779 fork_copy: user/cygwin data pass 2 failed, 0x9E0000..0xA95000, done 0, windows pid 4294443697, Win32 error 8
./configure: fork: Resource temporarily unavailable
6903956 [main] sh 509779 fork_copy: user/cygwin data pass 2 failed, 0x9E0000..0xA95000, done 0, windows pid 4294481317, Win32 error 8
./configure: fork: Resource temporarily unavailable

This ocurrs during the 'second pass' of configure as it had all ready
checked string.h earlier. The OS I'm using is Windows 98.

Is there some setting I can use to make this resource available?

Thank you, Elizabeth

Bob Friesenhahn wrote:
> 
> I found that the command
> 
>   convert -font arial -pointsize 30 "label:Hi there" outfile.jpg
> 
> fails when executed via the beta version of MSYS but works fine from
> the Windows command shell or via Cygwin.  I assume that MSYS is
> overagressive with converting command arguments to paths.  The
> argument "label:Hi there" is clearly not a valid path.
> 

I've attached a file arg.exe.gz.  Put it in /tmp nad gunzip it.  Then
replace the `convert' with `/tmp/arg'.  The result is a listing of
arugments as seen by the arg program.  These arguments will be the same
that are seen by the convert program.  In my sandbox, the arguments
appear to be what you would expect to see, i.e.: there are no
conversions.

Earnie.