[ ghc-Bugs-1197552 ] Adjustor creation not supported on x86_64
Bugs item #1197552, was opened at 2005-05-08 07:16 Message generated for change (Settings changed) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1197552group_id=8032 Category: Runtime System Group: 6.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Simon Marlow (simonmar) Summary: Adjustor creation not supported on x86_64 Initial Comment: Am hopeing to get gtk2hs working with the amd 64-bit version of ghc-6.4, but encounter the following runtime error: helloworld: internal error: adjustor creation not supported on this platform Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ Using Fedora's precompiled ghc64-6.4-5.x86_64.rpm. If anyone knows a way around this, or what flags (if any) can be specified to permit comilation of 32-bit ELF's from Haskell code in a 64-bit environment, lemme know. Cheers, [EMAIL PROTECTED] -- Comment By: Simon Marlow (simonmar) Date: 2005-05-09 11:58 Message: Logged In: YES user_id=48280 This has been implemented, and will be in 6.4.1. There are reports of failures with the current code, which I still have to look into, however. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1197552group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1097471 ] amd64: adjustor creation not supported
Bugs item #1097471, was opened at 2005-01-06 20:55 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1097471group_id=8032 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Pasch (aanno) Assigned to: Nobody/Anonymous (nobody) Summary: amd64: adjustor creation not supported Initial Comment: Hello, when trying to use wxhaskell on ghc-6.2.2 on an amd64 (unregistered gentoo build) the following happend: $ ./a.out a.out: internal error: adjustor creation not supported on this platform Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ I'm not sure if this is a bug because amd64 is not officially supported. -- Comment By: Simon Marlow (simonmar) Date: 2005-05-09 11:59 Message: Logged In: YES user_id=48280 Re-opened, and moved to bugs. -- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-09 07:33 Message: Logged In: YES user_id=139853 (Well fwiw all gtk2hs-0.9.7/demos segfault for me too.) -- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-09 00:45 Message: Logged In: YES user_id=139853 Testing more carefully today with patched ghc-6.4 instead (if it should make difference) I seeing segfaults with some wx samples demos. However I'm not certain if this is a ghc, wxhaskell, or even wxwidgets issue yet. -- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-08 08:32 Message: Logged In: YES user_id=139853 Just naively replacing DsForeign.lhs and Adjustor.c with the current versions from cvs trunk seems to work well so far though. :-) [ At least I got wxhaskell samples running with them on ghc-6-4-branch. :] -- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-07 02:07 Message: Logged In: YES user_id=139853 I tried ghc-6-4-branch to test this, but it seems the changes have not been merged there yet. -- Comment By: Simon Marlow (simonmar) Date: 2005-03-11 09:19 Message: Logged In: YES user_id=48280 Sorry :-( I implemented this yesterday. It was too late for 6.4, though (it'll be in 6.4.1). If you're interested in the code, take a look at Adjustor.c in CVS. I had to do some delicate hacking to work around the calling convention on x86_64, but fortunately it isn't as tricky as the powerpc version. Thanks for looking at this, and sorry I stepped on your toes! -- Comment By: Thomas Pasch (aanno) Date: 2005-03-11 08:31 Message: Logged In: YES user_id=349837 OK, I'm trying this. First I tried to do it the very same way as in x86: pushing hptr and obscure_ret_addr to stack. Of course, this doesn't work out because x86_64 does use REGISTER for the first 6 (in) arguments/paramenters. Next I tried to get hptr as second/#2 and obscure_ret_addr as first/#1 REGISTER parameter, shifting all REGISTER by 2 (and pushing arguments #6 and #5) to stack. Of course this does not work because obscure_ret is the (faked) return address and should be on the stack. My main problem is that I don't understand what is the the second argument (BaseReg) of StgRun(StgFunPtr f, StgRegTable *basereg) in StgCRun.c . How is this used in x86??? For me x86 stack for _ccall in Adjustor.c looks like: ??? 2nd arg to called haskell land function ??? 1st arg to called haskell land function ??? obsolete_ret_addr hptr obscure_ret_addr From this it is difficult for me to see any BaseReg joining the game. In other architectures (i.e. sparc) the in REGISTER are a shifted by 2 as well. But in this architecture you don't need the obscure_ret_addr stuff. The bottom line is the following: I understand ghc adjustor, x86, and x86_64 calling convention. BUT the x86 part concering the BaseReg is pretty undocumented. Perhaps someone could give me a hand being more verbose in what is needed in the x86_64 adjustor... Cheers, aanno -- Comment By: Wolfgang Thaller (wthaller) Date: 2005-01-20 22:29 Message: Logged In: YES user_id=566359 The StgFunPtr that is passed to createAdjustor is a pointer to a normal C function (using the standard C calling convention) that takes as it's first argument the StgStablePtr hptr, a second dummy argument of the same size that is ignored (this is to help the implementation for the x86 ABI), and then all the arguments that were passed from the constructor. Note that if
problem with xlib binding
Hi, Hmm, have the new xlib bindings been tested? For instance, when I run the following program: module Main where import Graphics.X11.Xlib import Graphics.X11.Xlib.Display main :: IO () main = do display - openDisplay root - rootWindow display $ defaultScreen display getGeometry display root closeDisplay display return () It prints out: xtest: user error (Error bad status 1 raised in function getGeometry) From the code it looks like the haskell getGeometry is calling XGetGeometry - which has type Status XGetGeometry(...) - and interpreting the 1 return value as an error (via the internal wrapper 'throwUnlessSuccess' which takes 0 for success). But the Xlib Programming Manual says Some errors, such as failure to open a font, are indicated by return values of type Status on the appropriate routine ... The returned values are *zero* on failure and *nonzero* on success. (emphasis added) So unless I'm really misinterpreting things, the binding to each and every one of the 13 functions that uses 'throwUnlessSuccess' is wrong. Well, before I realized this I'd gone ahead and written a reasonably significant program against the binding assuming that at least the basics would work, but it seems there is some distance to go before it is usable. One would think that with a Stability: provisional library at least every function has been run successfully once, but I can't imagine that this is the case. Is there even a working Haskell version of 'basicwin' from the Xlib Programming Manual? This would also be a helpful example for users. Thanks, Frederik -- http://ofb.net/~frederik/ ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1198393 ] Program aborts with segmentation fault when profiling used.
Bugs item #1198393, was opened at 2005-05-09 09:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1198393group_id=8032 Category: Profiling Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Program aborts with segmentation fault when profiling used. Initial Comment: I have a program that I have compiled under ghc6.5 (downloaded from the CVS repository on May 5/6), on Fedora-2 core running on a PC. This will run fine when compiled without profiling. With profiling enabled (-prof -auto-all with GHC, and +RTS -p for the program), it aborts, with the message internal error: Segmentation fault. The same program will compile and run, both with and without profiling, under ghc6.2.1. I have also tried with different datasets, and the same pattern occurs. I updated my ghc installation from CVS today (9th May), but have not been able to update my ghc installation to see if this problem has been removed, as the fptools-level build process is failing, with the Haddock build complaining that parsec-1.0 is an unknown package when building Utils.hs; building in the ghc dir results in a failure to find a module Version when building Main.hs in the utils/ghc-pkg area. The program and dataset are contained in the attached gzip'd tar file. I compile it (without profiling) using ghc --make -fglasgow-exts -o Reader Reader.hs -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1198393group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1198393 ] Program aborts with segmentation fault when profiling used.
Bugs item #1198393, was opened at 2005-05-09 09:21 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1198393group_id=8032 Category: Profiling Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Program aborts with segmentation fault when profiling used. Initial Comment: I have a program that I have compiled under ghc6.5 (downloaded from the CVS repository on May 5/6), on Fedora-2 core running on a PC. This will run fine when compiled without profiling. With profiling enabled (-prof -auto-all with GHC, and +RTS -p for the program), it aborts, with the message internal error: Segmentation fault. The same program will compile and run, both with and without profiling, under ghc6.2.1. I have also tried with different datasets, and the same pattern occurs. I updated my ghc installation from CVS today (9th May), but have not been able to update my ghc installation to see if this problem has been removed, as the fptools-level build process is failing, with the Haddock build complaining that parsec-1.0 is an unknown package when building Utils.hs; building in the ghc dir results in a failure to find a module Version when building Main.hs in the utils/ghc-pkg area. The program and dataset are contained in the attached gzip'd tar file. I compile it (without profiling) using ghc --make -fglasgow-exts -o Reader Reader.hs -- Comment By: Nobody/Anonymous (nobody) Date: 2005-05-09 09:23 Message: Logged In: NO Submitter forgot to add: contact email address is David Duke, email [EMAIL PROTECTED] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1198393group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1198393 ] Program aborts with segmentation fault when profiling used
Hi, I also have (a rather large) program (not included) that segfaults when compiled with profiling. I use the ghc-6.4 linux binary distribution from the web. It is not even necessary to call the program with +RTS -p -RTS. There is no problem with ghc-6.2.2, except that the old version uses its own copy of the fgl, Data.Map and Data.Set. If I let my Map and Set module reexport the ghc-6.4 library modules Data.Map and Data.Set then the program does not terminate if compiled without profiling and without optimization (with optimization it terminates, profiling segfaults in all cases). Any idea what I should do (and is not too time consuming)? Christian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1097471 ] amd64: adjustor creation not supported
Bugs item #1097471, was opened at 2005-01-07 05:55 Message generated for change (Comment added) made by juhp You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1097471group_id=8032 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Pasch (aanno) Assigned to: Nobody/Anonymous (nobody) Summary: amd64: adjustor creation not supported Initial Comment: Hello, when trying to use wxhaskell on ghc-6.2.2 on an amd64 (unregistered gentoo build) the following happend: $ ./a.out a.out: internal error: adjustor creation not supported on this platform Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ I'm not sure if this is a bug because amd64 is not officially supported. -- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-10 09:19 Message: Logged In: YES user_id=139853 Or should I open a new bug for the segfaulting? :) -- Comment By: Simon Marlow (simonmar) Date: 2005-05-09 20:59 Message: Logged In: YES user_id=48280 Re-opened, and moved to bugs. -- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-09 16:33 Message: Logged In: YES user_id=139853 (Well fwiw all gtk2hs-0.9.7/demos segfault for me too.) -- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-09 09:45 Message: Logged In: YES user_id=139853 Testing more carefully today with patched ghc-6.4 instead (if it should make difference) I seeing segfaults with some wx samples demos. However I'm not certain if this is a ghc, wxhaskell, or even wxwidgets issue yet. -- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-08 17:32 Message: Logged In: YES user_id=139853 Just naively replacing DsForeign.lhs and Adjustor.c with the current versions from cvs trunk seems to work well so far though. :-) [ At least I got wxhaskell samples running with them on ghc-6-4-branch. :] -- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-07 11:07 Message: Logged In: YES user_id=139853 I tried ghc-6-4-branch to test this, but it seems the changes have not been merged there yet. -- Comment By: Simon Marlow (simonmar) Date: 2005-03-11 18:19 Message: Logged In: YES user_id=48280 Sorry :-( I implemented this yesterday. It was too late for 6.4, though (it'll be in 6.4.1). If you're interested in the code, take a look at Adjustor.c in CVS. I had to do some delicate hacking to work around the calling convention on x86_64, but fortunately it isn't as tricky as the powerpc version. Thanks for looking at this, and sorry I stepped on your toes! -- Comment By: Thomas Pasch (aanno) Date: 2005-03-11 17:31 Message: Logged In: YES user_id=349837 OK, I'm trying this. First I tried to do it the very same way as in x86: pushing hptr and obscure_ret_addr to stack. Of course, this doesn't work out because x86_64 does use REGISTER for the first 6 (in) arguments/paramenters. Next I tried to get hptr as second/#2 and obscure_ret_addr as first/#1 REGISTER parameter, shifting all REGISTER by 2 (and pushing arguments #6 and #5) to stack. Of course this does not work because obscure_ret is the (faked) return address and should be on the stack. My main problem is that I don't understand what is the the second argument (BaseReg) of StgRun(StgFunPtr f, StgRegTable *basereg) in StgCRun.c . How is this used in x86??? For me x86 stack for _ccall in Adjustor.c looks like: ??? 2nd arg to called haskell land function ??? 1st arg to called haskell land function ??? obsolete_ret_addr hptr obscure_ret_addr From this it is difficult for me to see any BaseReg joining the game. In other architectures (i.e. sparc) the in REGISTER are a shifted by 2 as well. But in this architecture you don't need the obscure_ret_addr stuff. The bottom line is the following: I understand ghc adjustor, x86, and x86_64 calling convention. BUT the x86 part concering the BaseReg is pretty undocumented. Perhaps someone could give me a hand being more verbose in what is needed in the x86_64 adjustor... Cheers, aanno -- Comment By: Wolfgang Thaller (wthaller) Date: 2005-01-21 07:29 Message: Logged In: YES user_id=566359 The StgFunPtr that is passed to createAdjustor is a pointer to a normal C function (using the standard C calling convention) that takes as it's first
[ ghc-Bugs-1198673 ] can't build jhc with package depending on lang installed
Bugs item #1198673, was opened at 2005-05-10 09:28 Message generated for change (Comment added) made by juhp You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1198673group_id=8032 Category: libraries (other) Group: 6.4 Status: Open Resolution: None Priority: 5 Submitted By: Jens-Ulrik Petersen (juhp) Assigned to: Nobody/Anonymous (nobody) Summary: can't build jhc with package depending on lang installed Initial Comment: When I try to build jhc with ghc and have wxhaskell installed, the build fails because although lang-1.0 is hidden somehow it is exposed (by --make??) by being a dependency of the wxcore package. If I uninstall wxhaskell then there is no problem... however it is annoying having to uninstall and re-install pkgs just to build something. The same problem occurs with hs-plugins installed (instead of wxhaskell) iirc. -- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-10 11:17 Message: Logged In: YES user_id=139853 I quite forgot, and making this even more relevant ;) , this also affects building ghc-6.4 itself... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1198673group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1198673 ] can't build ghc with package depending on lang installed
Bugs item #1198673, was opened at 2005-05-10 09:28 Message generated for change (Comment added) made by juhp You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1198673group_id=8032 Category: Compiler Group: 6.4 Status: Open Resolution: None Priority: 5 Submitted By: Jens-Ulrik Petersen (juhp) Assigned to: Nobody/Anonymous (nobody) Summary: can't build ghc with package depending on lang installed Initial Comment: When I try to build jhc with ghc and have wxhaskell installed, the build fails because although lang-1.0 is hidden somehow it is exposed (by --make??) by being a dependency of the wxcore package. If I uninstall wxhaskell then there is no problem... however it is annoying having to uninstall and re-install pkgs just to build something. The same problem occurs with hs-plugins installed (instead of wxhaskell) iirc. -- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-10 11:27 Message: Logged In: YES user_id=139853 In fact it segfaults: ghc-6.4 -H16m -O -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/compMan -istage1/ndpFlatten -istage1/iface -istage1/cmm -Istage1 -DOMIT_NATIVE_CODEGEN -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package unix -package Cabal -recomp -Rghc-timing -H16M '-#include hschooks.h' -i../lib/compat-c types/Generics.lhs -o stage1/types/Generics.o -ohi stage1/types/Generics.hi types/Generics.lhs:1:0: Module `Generics' is a member of package lang-1.0. To compile this module, please use -ignore-package lang-1.0. ghc: 73454848 bytes, make[3]: *** [stage1/types/Generics.o] Segmentation fault make[2]: *** [all] Error 1 -- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-10 11:17 Message: Logged In: YES user_id=139853 I quite forgot, and making this even more relevant ;) , this also affects building ghc-6.4 itself... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1198673group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1198765 ] make depend of ghc-6.5 segfaults on x86-64
Bugs item #1198765, was opened at 2005-05-10 13:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1198765group_id=8032 Category: Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jens-Ulrik Petersen (juhp) Assigned to: Nobody/Anonymous (nobody) Summary: make depend of ghc-6.5 segfaults on x86-64 Initial Comment: Building current anoncvs HEAD with ghc-6.4 gives a segfault during make depend on x86_64: ../../glafp-utils/mkdependC/mkdependC -f .depend -IControl -IControl/Concurrent -IControl/Parallel -IControl/Monad -IControl/Monad/ST -IData -IData/Generics -IData/Array -IData/Array/IO -IData/STRef -IDebug -IForeign -IForeign/C -IForeign/Marshal -IGHC -ISystem -ISystem/Console -ISystem/Mem -ISystem/IO -ISystem/Posix -ISystem/Process -ISystem/Directory -IText -IText/Html -IText/PrettyPrint -IText/ParserCombinators -IText/Regex -IText/Show -IText/Read -I../../ghc/includes -s p -- -O-- System/CPUTime_hsc.c System/Time_hsc.c Text/Regex/Posix_hsc.c ../../ghc/compiler/ghc-inplace -M -optdep-f -optdep.depend -optdep-s -optdepp -osuf o-H16m -O -fglasgow-exts -cpp -Iinclude -#include HsBase.h -funbox-strict-fields -ignore-package base -O -Rghc-timing -fgenerics -fgenerics Control/Arrow.hs Control/Concurrent.hs Control/Concurrent/Chan.hs Control/Concurrent/MVar.hs Control/Concurrent/QSem.hs Control/Concurrent/QSemN.hs Control/Concurrent/SampleVar.hs Control/Exception.hs Control/Monad.hs Control/Monad/Fix.hs Control/Monad/ST.hs Control/Monad/ST/Lazy.hs Control/Monad/ST/Strict.hs Control/Parallel.hs Control/Parallel/Strategies.hs Data/Array.hs Data/Array/Base.hs Data/Array/Diff.hs Data/Array/IArray.hs Data/Array/IO.hs Data/Array/IO/Internals.hs Data/Array/MArray.hs Data/Array/ST.hs Data/Array/Storable.hs Data/Array/Unboxed.hs Data/Bits.hs Data/Bool.hs Data/Char.hs Data/Complex.hs Data/Dynamic.hs Data/Either.hs Data/Eq.hs Data/FiniteMap.hs Data/FunctorM.hs Data/Generics.hs Data/Generics/Aliases.hs Data/Generics/Basics.hs Data/Generics/Instances.hs Data/Generics/Schemes.hs Data/Generics/Text.hs Data/Generics/Twins.hs Data/Graph.hs Data/HashTable.hs Data/IORef.hs Data/Int.hs Data/IntMap.hs Data/IntSet.hs Data/Ix.hs Data/List.hs Data/Map.hs Data/Maybe.hs Data/Monoid.hs Data/Ord.hs Data/PackedString.hs Data/Queue.hs Data/Ratio.hs Data/STRef.hs Data/STRef/Lazy.hs Data/STRef/Strict.hs Data/Set.hs Data/Tree.hs Data/Tuple.hs Data/Typeable.hs Data/Unique.hs Data/Version.hs Data/Word.hs Debug/Trace.hs Foreign.hs Foreign/C.hs Foreign/C/Error.hs Foreign/C/String.hs Foreign/C/Types.hs Foreign/Concurrent.hs Foreign/ForeignPtr.hs Foreign/Marshal.hs Foreign/Marshal/Alloc.hs Foreign/Marshal/Array.hs Foreign/Marshal/Error.hs Foreign/Marshal/Pool.hs Foreign/Marshal/Utils.hs Foreign/Ptr.hs Foreign/StablePtr.hs Foreign/Storable.hs GHC/Arr.lhs GHC/Base.lhs GHC/Conc.lhs GHC/ConsoleHandler.hs GHC/Dotnet.hs GHC/Enum.lhs GHC/Err.lhs GHC/Exception.lhs GHC/Exts.hs GHC/Float.lhs GHC/ForeignPtr.hs GHC/Handle.hs GHC/IO.hs GHC/IOBase.lhs GHC/Int.hs GHC/List.lhs GHC/Num.lhs GHC/PArr.hs GHC/Pack.lhs GHC/PrimopWrappers.hs GHC/Ptr.lhs GHC/Read.lhs GHC/Real.lhs GHC/ST.lhs GHC/STRef.lhs GHC/Show.lhs GHC/Stable.lhs GHC/Storable.lhs GHC/TopHandler.lhs GHC/Unicode.hs GHC/Weak.lhs GHC/Word.hs Numeric.hs Prelude.hs System/CPUTime.hs System/Cmd.hs System/Console/GetOpt.hs System/Directory.hs System/Directory/Internals.hs System/Environment.hs System/Exit.hs System/IO.hs System/IO/Error.hs System/IO/Unsafe.hs System/Info.hs System/Locale.hs System/Mem.hs System/Mem/StableName.hs System/Mem/Weak.hs System/Posix/Internals.hs System/Posix/Signals.hs System/Posix/Types.hs System/Process.hs System/Process/Internals.hs System/Random.hs System/Time.hs Text/Html.hs Text/Html/BlockTable.hs Text/ParserCombinators/ReadP.hs Text/ParserCombinators/ReadPrec.hs Text/PrettyPrint.hs Text/PrettyPrint/HughesPJ.hs Text/Printf.hs Text/Read.hs Text/Read/Lex.hs Text/Regex.hs Text/Regex/Posix.hs Text/Show.hs Text/Show/Functions.hs ghc: 169931752 bytes, make[2]: *** [depend] Segmentation fault -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1198765group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
