Re: Cannot build 5.02.2 on Solaris 2.7
I should have followed your suggestion to to rebuild gcc for Solaris 2.7 right away. After rebuilding gcc, the source build and install of 5.02.2 had no problems. I am really sorry having wasted your time with something I had control over myself. While I am curious what difference in the assembly files made the ghc-split perl script fail with a bus error, there here is probably not much value in pursuing this. Let me know otherwise and I will try to capture the intermediate files for analysis. Thanks again, Martin Martin Dorr wrote: Simon Marlow wrote: $ gcc -v Reading specs from .../gcc-lib/sparc-sun-solaris2.5.1/2.95.2/specs gcc version 2.95.2 19991024 (release) I don't know if this is relevant, but the above gcc looks like it was built on Solaris 2.5, but you're on a 2.7 system. Perhaps rebuild gcc to be on the safe side? I wish I could, but I am tied in using a much larger set of tools with many other people running Solaris 2.5.1, 2.7, and 2.8. So far we have not found any problems running those 2.5.1 compiled tools on any of our systems. But, as you said, there is always a chance and I will keep it in mind. Just so I'm clear on what we're actually examining here: this is the 5.02.2 sources built using the 5.02.2 binary distribution, right? Yes You're not using 5.02.1 to build with? (it'll be easier to track down if we're bootstrapping 5.02.2 with itself). I ran into the problem using 5.02.1 binaries, upgrading to 5.02.2 did not help. Could you try changing the heap size when running the offending compilation and see if the core dump goes away? If it doesn't vary with the heap size, then it is probably much easier to track down because it won't be GC-related. I grabed the failing invocation and added +RTS -H10m, and then -H20m. All invocations fail the same way. I tried looking at the core dump with ddd, but it got an internal bus error while loading the the core file. gdb shouldn't crash (I hope). If it does, we're up the creek. Using gdb, I found that the core was from a perl invocation. Using -v3 I found ghc-split to dump core. : *** Splitter /home/dorr/func/haskell/sources/ghc-5.02.2/ghc/driver/split/ghc-split /tmp/ghc21821.split_s /tmp/ghc21821.split /tmp/ghc21821.split Bus Error - core dumped : How can I preserve the tmp files, so I can debug the perl run? I don't know anything about what split is supposed to achieve. Where should I read up on this? Martin ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Cannot build 5.02.2 on Solaris 2.7
Simon Marlow wrote: $ gcc -v Reading specs from .../gcc-lib/sparc-sun-solaris2.5.1/2.95.2/specs gcc version 2.95.2 19991024 (release) I don't know if this is relevant, but the above gcc looks like it was built on Solaris 2.5, but you're on a 2.7 system. Perhaps rebuild gcc to be on the safe side? I wish I could, but I am tied in using a much larger set of tools with many other people running Solaris 2.5.1, 2.7, and 2.8. So far we have not found any problems running those 2.5.1 compiled tools on any of our systems. But, as you said, there is always a chance and I will keep it in mind. Just so I'm clear on what we're actually examining here: this is the 5.02.2 sources built using the 5.02.2 binary distribution, right? Yes You're not using 5.02.1 to build with? (it'll be easier to track down if we're bootstrapping 5.02.2 with itself). I ran into the problem using 5.02.1 binaries, upgrading to 5.02.2 did not help. Could you try changing the heap size when running the offending compilation and see if the core dump goes away? If it doesn't vary with the heap size, then it is probably much easier to track down because it won't be GC-related. I grabed the failing invocation and added +RTS -H10m, and then -H20m. All invocations fail the same way. I tried looking at the core dump with ddd, but it got an internal bus error while loading the the core file. gdb shouldn't crash (I hope). If it does, we're up the creek. Using gdb, I found that the core was from a perl invocation. Using -v3 I found ghc-split to dump core. : *** Splitter /home/dorr/func/haskell/sources/ghc-5.02.2/ghc/driver/split/ghc-split /tmp/ghc21821.split_s /tmp/ghc21821.split /tmp/ghc21821.split Bus Error - core dumped : How can I preserve the tmp files, so I can debug the perl run? I don't know anything about what split is supposed to achieve. Where should I read up on this? Martin ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Cannot build 5.02.2 on Solaris 2.7
Simon Marlow wrote: I've just finished building 5.02.3 on sparc-solaris, and didn't get any core dumps, so there must be something different about your setup. What version of gcc are you using? What version of GHC are you bootstrapping with? $ gcc -v Reading specs from .../gcc-lib/sparc-sun-solaris2.5.1/2.95.2/specs gcc version 2.95.2 19991024 (release) For GHC I tried 5.02.1 and 5.02.2 binaries for solaris. The core dump due to bus error occurs when building from 5.02.2 AND 5.02.3 sources. It did not occur when building from 5.02.1 sources and setting GhcRtsHcOpts = -optc-DDEBUG -optc-g -keep-hc-file GhcRtsCcOpts = -g in mk/build.mk. I don't know whether the default build components have changed from 5.02.1 to 5.02.2, and Monad.p_o was never built (I have no make log from that build and had to remove the source tree to make room for the 5.02.2 source). I tried looking at the core dump with ddd, but it got an internal bus error while loading the the core file. Any suggestions on what to look at to get more insight into the root cause of this? What's special about Monad.p_o? As part of this build, ghc-inplace was used many times before to compile *.o's (incl Monad.o) and other *.p_o's without problems. $ echo prefix = /home/dorr/func/haskell/installs/ghc-5.02.2 mk/build.mk Better to set prefix at configure time (i.e. ./configure --prefix=...). Better as in simpler, or really better? After a default build works, I need to set GhcRtsHcOpts, GhcRtsCcOpts, and potentially other parameters. Shouldn't I just start a build.mk anyway rather then pass all of these into ./configure? Are there guidelines on when to define parameters via ./configure options versus build.mk? $ cd ghc $ ./configure not necessary - the top-level configure script invokes the lower ones. $ cd rts/gmp $ ./configure not necessary - this is invoked by the Makefile in ghc/rts if necessary. Thanks for pointing this out. The instructions to run autoconf in directories with configure.in led me to believe I need to run ./configure too. When I am excited to get it right, the best build instructions don't help ;-). Martin ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Cannot build 5.02.2 on Solaris 2.7
Simon Marlow wrote: If I do the following ... I think these bugs (the illegal -x option to ld, and the messed up installation directories) were fixed in 5.02.2. Could you try building that version instead? Cheers, Simon Well, the -x options are still there and now I dump core while compiling with the new ghc-inplace opbject. Below is the trace ... $ tar xvfi ghc-5.02.2-src-1.tar $ cd ghc-5.02.2 $ cp -r ../happy-1.11/happy . $ echo prefix = /home/dorr/func/haskell/installs/ghc-5.02.2 mk/build.mk $ find . -name configure ./ghc/rts/gmp/configure ./ghc/configure ./configure $ ./configure $ cd ghc $ ./configure $ cd rts/gmp $ ./configure $ cd ../../.. $ make : /usr/ccs/bin/ld: illegal option -- x - remove ld -x options in mk/target.mk per posting on buglist - remove ld -x options in ghc/lib/std/Makefile per posting on buglist $ make : rm -f Monad.p_o; if [ ! -d Monad ]; then mkdir Monad; else /usr/bin/find Monad -name '*.p_o' | xargs rm -f __rm_food; fi; ../../../ghc/compiler/ghc-inplace -ldl -fvia-C -cpp -fglasgow-exts -O -Rghc-timing -package-name std -split-objs -hisuf p_hi -h csuf p_hc -osuf p_o -prof -c Monad.lhs -o Monad.p_o Bus Error - core dumped ghc: 65936848 bytes, 21 GCs, 966856/1743392 avg/max bytes residency (3 samples), 7M in use, 0.02 INIT (0.02 elapsed), 1.81 MUT (5.98 elapsed), 0.63 GC (0.66 elapsed) :ghc make[4]: *** [Monad.p_o] Error 1 make[3]: *** [all] Error 1 make[2]: *** [all] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/dorr/func/haskell/sources/ghc-5.02.2/ghc' make: *** [all] Error 1 I tried another make with the same result. Martin ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Cannot install 5.02.1 on Solaris 2.7 (building from source)
If I do the following ... $ tar xvfi ../ghc-5.02.1-src-1.tar $ tar xvfi ../happy-1.11-src.tar $ cd ghc-5.02.1 $ cp -r ../happy-1.11/happy . $ echo prefix = /home/dorr/func/haskell/installs mk/build.mk $ ./configure $ cd ghc/rts/gmp $ ./configure $ cd - $ cd ghc $ ./configure # not sure this is needed, it's run via make again $ cd - $ make : /usr/ccs/bin/ld: illegal option -- x [- remove ld -x options in mk/target.mk per posting on buglist] [- remove ld -x options in ghc/lib/std/Makefile] $ make $ make install : make[1]: Leaving directory `/home/dorr/func/haskell/sources/ghc-5.02.1/ghc' make[1]: Entering directory `/home/dorr/func/haskell/sources/ghc-5.02.1/hslibs' ===fptools== Recursively making `install' in lang concurrent posix util data text net hssource tools ... PWD = /home/dorr/func/haskell/sources/ghc-5.02.1/hslibs ==fptools== make install -wr; in /home/dorr/func/haskell/sources/ghc-5.02.1/hslibs/lang ===fptools== Recursively making `install' in cbits ... PWD = /home/dorr/func/haskell/sources/ghc-5.02.1/hslibs/lang ==fptools== make install --no-print-directory -r; in /home/dorr/func/haskell/sources/ghc-5.02.1/hslibs/lang/cbits mkdir /home/dorr/func/haskell/installs/lib/ghc-5.02.1 mkdir: Failed to make directory /home/dorr/func/haskell/installs/lib/ghc-5.02.1; File exists make[3]: *** [install] Error 2 make[2]: *** [install] Error 1 make[1]: *** [install] Error 1 make[1]: Leaving directory `/home/dorr/func/haskell/sources/ghc-5.02.1/hslibs' make: *** [install] Error 1 $ uname -a SunOS anasazi 5.7 Generic_106541-12 sun4u sparc SUNW,Ultra-5_10 $ For some reason the library sub-directories are set differentlly for ghc and hslibs. The ghc install put its compiler object as the name the hslib install tries to use as a directory. Maybe version.mk was not found. What did I screw up in my minimalistic compile attempt? Martin ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
GHC 4.02 install problem on Win95
In case the following is already known please discard it (I just joined the bugs list and have not seen any email on it or how to search the bugs list archives). I just installed GHC 4.02 binaries on Win95 and ran into a little problem. After selecting 'make install' copying the binaries errors out on 'hp2ps' not found because the .exe is missing on the name in the file list (or incorrectly named in the directory). A simple work-around is to update the line 'PACKAGE_BINS = hp2ps' to include the .exe extension. The installation script seems to run fine after this change. Let me know if I should make additional changes to get the installation right. Martin PS: My first attempt to report the problem using the 'touch' link on the web page announcing the availability failed with my email being rejected due to an incompatibility/authorization problem (I've never seen anything like it before, must be another MS product feature ;-).
