#3609: ar.exe: Bad file number
-------------------------------+--------------------------------------------
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.10.4
Severity: normal | Keywords:
Difficulty: Unknown | Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-------------------------------+--------------------------------------------
John Earle writes:
* Hardware. Operating System: 32-Bit Edition of Windows Vista with
Service Pack 2 applied. CPU: Intel Pentium 4
* Software. MinGW 5.1.6 which is the current stable release. MinGW 5.1.6
does not install the latest version of gcc, however. It installs gcc
3.4.5.
* MSYS 1.0.11 which is the current version of MSYS. It installs GNU Make
3.81 among other things. The version of MSYS available at
http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows is
1.0.10.
* msysDTK-1.0.1 which is the current stable release and is the same
version available at
http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows.
* Preexisting version of GHC is 6.10.4 which is the current stable
release of GHC which was used to build GHC 6.10.4 from source.
* Those additional Haskell tools that were needed were downloaded from
http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows.
* !ActiveState Python 2.6.3.7 (current is 3.1.1.2, but is not
appropriate).
A build script along with a build procedure was prepared. These results do
not reflect what was needed to reach this point. Many hours of work were
required to achieve these results. These results were not the results that
were achieved initially. The directions provided for how to build GHC from
source proved insufficient. A workaround which was not described is
needed.
The build script runs make, the fast test suite, and make install. The
documentation is not built. In order for the test suite to complete
Windows Firewall had to be turned off which was something that was also
not specified in the directions. Where the test suite needed to be
unpacked to or should be named was furthermore not specified. These issues
among others make the build process very expensive. Once you have all your
ducks in the row, it is easier going, but that is how it usually is in
life.
Before proceeding remove the xargs shell script from the path. The xargs
shell script is the workaround described above.
Wait 1 hour and 1 minute.
{{{
make -C libraries all
make[2]: Entering directory `/Z/dev/ghc-6.10.4/src/libraries/ghc-prim'
(echo dist/build/cbits/longlong.o `find dist/build -name "*_stub.o"
-print`; find dist/build/GHC/Bool_split dist/build/GHC/Generics_split
dist/build/GHC/Ordering_split dist/build/GHC/PrimopWrappers_split
dist/build/GHC/IntWord32_split dist/build/GHC/IntWord64_split
dist/build/GHC/Tuple_split dist/build/GHC/Types_split
dist/build/GHC/Unit_split -name '*.o' -print) | xargs c:/MinGW/bin/ar.exe
q dist/build/libHSghc-prim-0.1.0.0.a
xargs: c:/MinGW/bin/ar.exe: Bad file number
make[2]: *** [dist/build/libHSghc-prim-0.1.0.0.a] Error 126
}}}
In prior attempts I did not receive this error so early. Notice that the
version of ar is c:/MinGW/bin/ar.exe. In
http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows
c:/MinGW/bin/ occurs in the path before the preexisting instance of GHC
just as is the case here. On a previous attempts I have gotten "xargs:
c:/ghc/ghc-6.10.4/bin/ar.exe: Argument list too long" and "xargs:
c:/ghc/ghc-6.10.4/bin/ar.exe: Bad file number". The path to ar appeared
hard coded which is confusing.
I moved the xargs shell script so that it appeared front most in the path
once more and resumed the build process from where it left off.
Wait 3 hours and 5 minutes. The build process completed successfully.
At 2 hours and 42 minutes later after the build process was resumed an
empty null file is created in the "Z:\dev" parent directory which an
immediate child of the root directory. Regardless of how deeply nested the
project directory is, it always appears in the dev directory.
If all goes well the build process has consistently taken 4 hours and 6
minutes.
The day before the build was completed with the workaround applied prior
to carrying out the procedure. Today, when the workaround was applied only
once an error was encountered and this resulted in additional unexpected
test suite failure, namely: conc049(normal). These were yesterdays
results:
{{{
OVERALL SUMMARY for test run started at The current date is: 2009.10.22
Enter the new date: (yy-mm-dd)
2403 total tests, which gave rise to
12815 test cases, of which
0 caused framework failures
10766 were skipped
1955 expected passes
76 expected failures
1 unexpected passes
17 unexpected failures
Unexpected passes:
system001(normal)
Unexpected failures:
2816(ghci)
DoParamM(normal)
cabal01(normal)
drvfail006(normal)
drvfail008(normal)
getPermissions001(normal,normal)
ghci028(ghci)
mod133(normal)
net001(normal)
signals004(normal)
tc183(normal)
tc217(normal)
tc220(normal)
tc223(normal)
tc232(normal)
tcfail126(normal)
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3609>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
