cygwin build_alias issue (and a possible workaround... really this time...)
Bogdan Vacaliuc
bvacaliuc at ngit.com
Wed Sep 15 03:15:01 UTC 2004
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
>
>
>
>
>
>
>
More information about the users
mailing list