cygwin build_alias issue (and a possible workaround... really this time...)

[Bogdan Vacaliuc]

Gene, Scott, everyone,

Chris Faylor has made a new cygwin snapshot that is showing promising results for me so far.  (150 iterations of configure-test, and
two successful configure/builds of mips-rtems-csb350).

Would those of you with their build environments setup under cygwin, please download and install the 09/14/04 snapshot (of the
/bin/cygwin1.dll) from:
http://www.cygwin.com/snapshots/

Instructions are here:
http://cygwin.com/faq/faq_2.html#SEC20

And let us know how the new snapshot fares against the test script and the configure/build itself on your systems.

I'm not sure what to make of the /bin/sh.exe, /bin/bash.exe thing for now.  I have also noticed increased likelyhood of configure
failure when sh.exe <= bash.exe.  I am running my tests with stock /bin/sh.exe as ash.  [the configure scripts appear to figure out
that they want bash and invoke themselves thusly]


I we may be shaking this thing loose...  :)

-bogdan


> -----Original Message-----
> From: Smith, Gene [mailto:gene.smith at siemens.com] 
> Sent: Tuesday, September 14, 2004 11:41 AM
> To: 'RTEMS Users'
> Subject: Re: cygwin build_alias issue (and a possible workaround...)
> 
> 
> Bogdan Vacaliuc wrote, On 9/14/2004 5:36 AM:
> 
> > Thanks Chris,
> > 
> > Hmm.  Well.  Interesting.  For me, ccjfail (without 
> --srcdir's) fails, 
> > but all the rest don't (within the time I'm willing to wait for).
> > 
> > Let's settle on ccjfail as the fail function (see if removing the 
> > --srcdir items (3 of them) still makes it fail for you), then our 
> > systems are in common.  In the attached script I made the default 
> > ccjfail
> > 
> > 
> >> I have and I attach the script for you plus the fail.log 
> (appended  
> >> together). Note, all the failing tests on WinME pass on WindowsXP 
> >> with MSYS. More below ...
> > 
> > 
> > Hmm.
> > 
> > There was some activity on the cygwin list recently.
> > 
> > http://cygwin.com/ml/cygwin/2004-09/msg00627.html
> > 
> > We're beginning to narrow down the issue after some straces were 
> > captured.  There is a M$ bug I referenced:
> > 
> > "BUG: Registry access from multiple threads might fail" (WinNT,
> > Win2K) 
> http://support.microsoft.com/default.aspx?scid=kb;en-us;176906
> > 
> > 
> > Which applies only to WinNT and Win2K, but not (apparently) 
> to WinXP?
> > 
> > 
> > 
> > Would everyone who is watching this thread, please let us 
> know if the 
> > attached script fails on their machine within a small number of 
> > iterations, and also what OS they are running?
> > 
> > $ ./test-configure
> > 
> > I'm particularly curious now if people with WinXP are 
> testing/building 
> > OK, but those with Win2K and otherwise are not. This would 
> lend some 
> > credence to M$ KB176906 and suggest a possible workaround in either 
> > the bash or the cygwin.dll code...
> > 
> > 
> > Thanks,
> > 
> > -bogdan
> 
> After updating to latest cygwin, 1.5.11-1, it ran 19 times before 
> failing with this message:
> 
> *** TEST 19 FAILS ***
> configure: error: invalid feature name: multilib
> 
> Then I ran it again and it failed quickly like this:
> 
> *** TEST 1 FAILS ***
> configure: error: invalid variable name: build_alias
> 
> Running
> Windows 2000
> 5.00.2195
> SP4
> 
> Then I checked and the upgrade had put ash back in /bin/sh. 
> Made /bin/sh 
> bash again and got:
> 
> $ ./test-configure.txt
> Running using function ccjfail()...
> ./test-configure.txt: line 152: [: too many arguments
> ./test-configure.txt: line 156: [: too many arguments
> *** TEST 0 FAILS ***
> configure: error: invalid variable name: build_alias
> 
> Made /bin/sh back to the default ash and it currently up to 
> TEST 50 with 
> no errors yet. So it appears the default /bin/sh works a bit 
> better than 
> when you make it bash.
> 
> 
> -gene
> 
> 
> 
> 
> 
> 
>