With both ghc6.2 and 6.2.20040915 on Linux, ghc --make cannot compile
the attached files and produces a confusing error message.
# ghc --make View.hs
Chasing modules from: View.hs
Compiling ViewType ( ./ViewType.hs, ./ViewType.o )
Compiling VersionGraphClient ( ./VersionGraphClient.hs,
Hello GHC bug fixers,
I just sent a program which ghc --make couldn't compile but
individual ghc -c commands could.
Now I have just tried to work around this, using Template Haskell
to use a data rather than newtype declaration for ghc6.2
Unfortunately the new code has the opposite problem! It
# ghc -fwarn-unused-imports C.hs
C.hs:1:
Warning: Module `A' is imported, but nothing from it is used
(except perhaps instances visible in `A')
However if I comment out the import of A I get
./B.hi-boot:3:
tcLookup: `A.A' is not in scope
In the type synonym declaration
Axel Simon wrote (snipped):
But if I have two layers over gtk 1.2 and 2.0 and both use the
hierarchical module system and are therefore marked as auto you would
have the same problem of linking in two versions of gtk which doesn't
work. Did I miss something?
I presume that Simon meant that only
Simon Peyton-Jones wrote:
It's documented behaviour.
* import Text.ParserCombinators.Parsec will work without any -package
flags, if any installed package has a module
Text.ParserCombinators.Parsec. It's very tiresome adding -package flags
all the time.
* The link step needs -package flags,
Alastair Reid wrote (snipped):
Why is it necessary to provide -package options at all?
ghc-pkg knows about all the packages in your system so it could just
implicitly add -package $x for every package when compiling or linking.
My current need at least is to disable the lang, text, data packages
With
ghc ParsecTest.hs -o pt
you get a link-time failure, because it looks as if the base package
Text.ParserCombinators.Parsec depends somehow on the package text.
module Main where
import Text.ParserCombinators.Parsec
ch = char 'C'
main =
do
seq ch (return
Ross Paterson wrote:
On Mon, Sep 06, 2004 at 12:10:09PM +0200, George Russell wrote:
With
ghc ParsecTest.hs -o pt
you get a link-time failure, because it looks as if the base package
Text.ParserCombinators.Parsec depends somehow on the package text.
Try -package parsec
OK, I have
According to
http://www.haskell.org/ghc/docs/latest/html/users_guide/options-sanity.html
there is a GHC option -fwarn-misc. But ghc-6.2.1 doesn't seem to have it.
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
Not so much a bug this as a whinge:
# ghc -c TH2.hs -fwarn-missing-signatures -fglasgow-exts
Loading package base ... linking ... done.
Loading package haskell98 ... linking ... done.
Loading package haskell-src ... linking ... done.
TH2.hs:6: Warning: Definition but no type signature for `a'
# ghc Unused.hs -fwarn-unused-binds -fglasgow-exts
Unused.hs:10: Warning: Defined but not used: Dummy
module Unused(Foo(..),ff) where
class Foo (v :: (* - *) - *) where
f :: v a - Int
ff :: Foo v = v a - Int
ff (_ :: (v :: (* - *) - *) a) = (f (error bar :: v Dummy))
data Dummy x = Dummy
When I have a collection of files to compile and
(1) I use --make to compile them together;
(2) they are recursive
it works the first time, but when I try to compile them the
second time I get messages about bogus duplicate instance
declarations, for example:
Skipping GlobalRegistry (
With ghc-6.2.1 compiled from source
tar -xzf instances2.tar.gz
cd instances2
gmake
produces the message:
AttributesType.hs:15:
Could not deduce (Show value)
from the context (AttributeValue (Radio value),
HasConfigRadioButton value,
# ghc -c FunnyError.hs
FunnyError.hs:7:
Couldn't match `Bool' against `[Char]'
Expected type: Bool
Inferred type: [Char]
In the definition of `b': b x Foo = ()
In the definition for method `b'
FunnyError.hs:9:
tcLookup: `FunnyError.$dmb' is not in scope
In the
Unpacking the attached bundle and running the following with ghc=GHC6.2
(Linux, compiled from the ghc-6.2 tag), produces the following:
# cd packagesbug
/home/ger/test/packagesbug
# CompileBug
/home/ger/test/packagesbug/package1
Chasing modules from: CompileFlags.hs
Compiling CompileFlags (
How do you install ghc so that ghc-pkg doesn't use the Solaris linker, but instead
the GNU linker which is called (here) gnu-ld?
Obviously it doesn't want to use the Solaris linker since that doesn't have
the --whole-archive option ghc-pkg needs.
___
Simon Marlow wrote (snipped):
BTW George: there are plenty of 6.1.xxx snapshots available - these
are the 6.2 prereleases.
There are, but no recent ones. What I would like to have had is a 6.2-epsilon
version, not 6.1 and a bit.
We don't snapshot along the STABLE branch at
the moment; no
I have just installed ghc6.2 on Linux. (I had to compile it from source because the
binaries insist on a glibc version we don't have.)
The attached module contains two functions (serverMain) and (clientMain).
clientMain opens a connection (to localhost) and sends some data along it,
then executes
For ghc6.0.1 on Linux
# ghc Test1.hs -c -fglasgow-exts -fallow-undecidable-instances
-fallow-overlapping-instances
# ghc Test2.hs -c -fglasgow-exts -fallow-undecidable-instances
-fallow-overlapping-instances
works.
But for ghc6.3.20031201 the second compilation produces the message:
The attached file causes a panic when compiled with ghc6.0 on Linux.
# ghc -fglasgow-exts TH.hs -c
ghc-6.0.1: panic! (the `impossible' happened, GHC version 6.0.1):
nameModule newLen0 {- v a35 -}
Please report it as a compiler bug to [EMAIL PROTECTED],
or
Template Haskell seems to be type-checking some quasi-quotes, even when they
are not going to be used. This is of course a terrible nuisance, since it
means it can't be used to work around interface incompatibilities between
libraries for different versions of GHC (such as the recent change in
Simon Peyton-Jones wrote (snipped):
Still, in your cpp-like application, I guess your story is that the
condition might evaluate to True only if the system configuration was
such that bar was in scope. If the condition evaluates to False, then
bar really might not be available.
OK, in TH
It seems as if the RPM and .tar.gz versions of ghc-6.0.1 are binary
incompatible. That is, a library built for one will not necessarily
work on the other. For example, libHSbase.a defines the symbol
GHCziRead_lvl18_closure in the .tar.gz version, which can be
externally called; however in the
It looks like I am going to have to hack the shell script that calls ghc, because
it needs to set LD_LIBRARY_PATH so that the executables can find libreadline. Would
it be possible to have an option to ./configure that set a library path to be used
by these scripts?
I have a problem with a handle for which hClose does not terminate. Unfortunately
it's too much work for me to narrow it down now, but perhaps it can be worked out
from these facts?
(1) it's a socket connection.
(2) it has BlockBuffering (Just 4096) set.
(3) it is possible that another thread is
Actually what I really need is peekCStringLen. This function can
surely avoid stack overflow by building up the result from right to
left?
I think for peekCString the solution might be to get the length using
the C function strlen (which is more optimised than a Haskell alternative)
and then call
The following program gives me a stack overflow for a file big.tex
15 bytes long.
-- Cut here --
module Main where
import Foreign.C.String
import Foreign.Ptr
import qualified GHC.IO
main =
do
(ptr,len) - GHC.IO.slurpFile big.tex
peekCStringLen (castPtr ptr,len)
return ()
What is going on here? Is it already fixed in 6.1?
# uname -a
Linux denebola 2.4.19-4GB #2 Mon Mar 31 10:57:24 CEST 2003 i686 unknown
# ghc DynExcep.hs -c -fglasgow-exts
# ghci
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.0, for Haskell 98.
/
Yes, I know functional languages are memory hogs, but really!
The following is on linux
# ghci
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.0, for Hask
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\/\/ /_/\/|_| Type :?
What is wrong here?
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.0, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\/\/ /_/\/|_| Type :? for help.
Loading package base ... linking ... done.
Prelude :def code (\ - do { let
Hello all, I have a file BinaryIO. This used to import a module
HGetCharHack to work around an annoying problem with ghc5.04 which
meant that hGetChar was blocking unexpectedly. However I see that
this problem has now been fixed in ghc6 (ta very much, Simon) so I
deleted the files
# uname -a
SunOS leo 5.8 Generic_108528-18 sun4u sparc SUNW,Sun-Fire-280R
# ./ghci
./ghci: /nfs/moussor/hdaume/lib/ghc-6.0/ghc-6.0: not found
Also the install process failed as follows:
./mkdirhier /usr/local/pub-bkb/ghc/ghc-6.0/share/ghc-6.0/html
if test -d share/html ; then cp -r share/html/*
The cd command on Linux considerately prints out the name of the
new directory, which it gets from the CDPATH. This has the unfortunate
side-effect of breaking gmake install for ghc6.0, which uses some shell
hackery of the form something like:
for i in `(cd share ; find .)`
where i's first value
(1) I think Posix.getFileStatus should respond to a file which isn't there with
something rather more helpful than
system error. For example, a No such file or directory message.
(2) The logical way of spotting whether a file is actually there is the
queryFile function, documented for example
Manuel M T Chakravarty wrote:
[snip]
Luckily, there is a workaround (discovered by Tom Moertel on
#haskell). If you include field names in the data
definition for which you derive Show and Read, it seems to
work fine.
[snip]
Thanks. I may try this, if I get time.
On Solaris:
# /home/ger/ghc-5.04.1.install/bin/ghci
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 5.04.1, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\/\/ /_/\/|_| Type :? for help.
Loading package base ...
In fact the problem is more drastic than I mentioned in my last message; division by 0
doesn't seem to be catchable at all. From this program
--- cut here ---
import Exception
main =
do
excep - Exception.try (seq (1 `div` 0) (return ()))
putStrLn
Simon Marlow wrote:
This was a bug in GHC's native code generator for SPARC,
which sometimes
misaligned the stack pointer. This has already been fixed in CVS (HEAD
and branch), but it didn't make it into 5.04, see:
uname -a:
SunOS titania 5.8 Generic_108528-15 sun4u sparc SUNW,Ultra-1
ghc --version:
The Glorious Glasgow Haskell Compilation System, version 5.04
gcc --version:
2.95.3
With the files in the attached archive unpacked:
ghc hw5.c TestHW5.hs -ffi -package posix -o hw5 -Wall
./hw5
Sorry, I haven't got time to narrow this down to a test case, but here are
what I hope are the key factors:
(1) We start up applications in a child process (forked with Posix.forkProcess)
by calling Posix.executeFile, wrapped in an Exception.catch handler (to detect
errors).
(2) Both the third
For example, with the attached test-package.conf file,
we see that -fglasgow-exts in the first case works (because the package is
loaded in the beginning), but in the second case it doesn't (because the
package is loaded during GHCi).
This also applies to -fallow-overlapping-instances and
Specifically I get
*** Exception: invalid argument
Action: hGetBuf
Handle: {loc=/tmp/d,type=readable,binary=False,buffering=block (8192)}
Reason: illegal buffer size 0
whether using 5.03.2 on Solaris or 5.03.20020410 on Linux.
___
I have a private package file (attached).
However, specifying this via -f to the new ghc-pkg has the
following unpleasant consequences:
(1) -l only knows about the packages in my private file, not in the
GHC one.
(2) When I try to add a new package to this file that depends on one
of the
With ghc-5.02.3 on Windows starting with a package containing an object with a large
String
I get the following message. Note the last line.
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 5.02.3, for Haskell 98.
/ /_\\/ __ / /___| |
(This is on sparc-solaris)
# /usr/local/pub-bkb/ghc/ghc-latest/bin/ghc --make resources/GUIValue.hs
resources/Colour.hs -fglasgow-exts
ghc-5.02.3: chasing modules from: resources/GUIValue.hs,resources/Colour.hs
Compiling GUIValue ( resources/GUIValue.hs, resources/GUIValue.o )
George Russell wrote:
[snip]
Personally I suspect multi-parameter type-classes
[snip]
I've changed my mind and now think it's because GHC was upset it couldn't find the
.hi file for GUIValue.hs in a directory on the import list. (Of course it shouldn't
be, it should know where the .hi file
Simon Marlow wrote:
George Russell wrote:
[snip]
Personally I suspect multi-parameter type-classes
[snip]
I've changed my mind and now think it's because GHC was upset
it couldn't find the
.hi file for GUIValue.hs in a directory on the import list.
(Of course it shouldn't
I have a program which comes to the end of the main action, but nevertheless won't go
away. Is this
a bug? When I give up and interrupt it, I get a message
fatal error: resurrectThreads: thread blocked in a strange way; could this be
connected?
Something is rotten in the state of dynamic types and multiparameter
type classes. I'd be grateful if you'd fix it soon, this is causing
me big difficulties.
I'm sorry if this is complicated, but I've already spent two hours
narrowing this bug down and the security are about to throw me out
of
According to the GHC libraries manual, 6.2.1: The Handle returned by connectTo and
accept is unbuffered by default. However, with such a handle and hPutStrLn,
I am getting buffering, even when use IO.hSetBuffering to NoBuffering. When I
put in an explicit hFlush after the hPutStrLn it
The attached file doesn't compile (ghc -fglasgow-exts), with the message
RecContext.hs:12:
Mismatched contexts
When matching the contexts of the signatures for
g :: forall a b. (Silly a b) = a - b - SillyType a - [String]
f :: forall a. SillyType a - [String]
The
(Yes, I know that's not very impressive, but you must all have been wondering what's
happened to me.)
The attached file, when compiled with ghc5.02.1, -fglasgow-exts
-fallow-overlapping-instances -fallow-undecidable-instances produces the error message
Haskell.hs:11: Illegal left hand side
Malcolm Wallace wrote, answering me:
On the contrary I'm glad to see that the Haskell standard is so sensible.
I edit Haskell using XEmacs, and I don't want to have to do an octal
or hexadecimal dump of my source code to determine whether a string
contains a tab, newline, return, line
Malcolm Wallace wrote:
[snip]
No he isn't. At least, I can't find anything in the Report which
disallows literal newline characters in a string literal.
Oh, hold on. The production
string - { graphic_|` | space | escape | gap }
does seem to disallow newline characters. But it
The attached interface file SimpleForm.hi provokes the following error from ghc5.02:
MainsimpleFormEx.hs:6:
failed to load interface for `SimpleForm':
Bad interface file: /home/ger/uni/htk/toolkit/SimpleForm.hi
/home/ger/uni/htk/toolkit/SimpleForm.hi:155 Interface file
DaVinciTypes defines the types DaVinciAnswer and the constructor Context.
(.hi file attached.)
So I would expect
import DaVinciTypes hiding (Context)
import qualified DaVinciTypes
to make DaVinciAnswer in scope, but DaVinciTypes.Context only available when so
qualified.
This doesn't appear to
ghci -iutil:events -syslib lang -syslib data -syslibconcurrent util/object.o
[ lots of stuff skipped ]
Events :load GuardedEvents
unloadObj: can't find `events/Events.o' to unload
ghc-5.00.2: panic! (the `impossible' happened, GHC version 5.00.2):
unloadObj: failed
Please report it as
In trying out a particularly large set of files (circa 450) with ghc --make I
get
ghc-5.00: panic! (the `impossible' happened, GHC version 5.00):
resource exhausted
Action: openFile
Reason: process file table full
File: /tmp/ghc14562.hspp
Please report it as a compiler bug to [EMAIL
I'm trying to get UniForM through ghc 5.00 (limping at the moment, as I
have to turn on -fasm -Onot to work around bugs previously reported) and
I get
ghc-5.00: panic! (the `impossible' happened, GHC version 5.00):
ERROR: Native code generator can't handle casm
Please report it as a
This is ghc5.00/Sparc, running with the following command line
/usr/local/pub-bkb/ghc/ghc-5.00/bin/ghc -c CVSHigh.hs -package concurrent -package
data -package net -package posix -package text -package util -package lang
I was just trying to compile the new ghc 5.00 on Sparc/Solaris and got this:
==fptools== gmake boot --no-print-directory -r;
in /home/ger/ghc-5.00/ghc/lib/std/cbits
../../../../glafp-utils/mkdependC/mkdependC -f .depend
Compiling the above Haskell file with ghc4.08.2 (Sparc-Solaris) and the hi files in
the attached
archive, options:
-c -package concurrent -package data -package net -package posix -package text
-package util -package lang -fglasgow-exts -fallow-overlapping-instances
Makefiles to compile GuardedChannels with
-funfolding-interface-threshold0) works. Many thanks for the quick service,
George Russell
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Simon Marlow wrote:
Ok, we'll need to investigate but this is going to be a tricky one to track
down. Is there any way you can try to narrow down the problem?
sigh Oh alright then. It's taken me some time but attached is a version
narrowed down to just two files. When you've unpacked it, go
Simon Peyton-Jones wrote:
It's a bug all right, and a bizarre one at that.
It's fixed in the before-ghci-branch.
I'm not quite certain when it got fixed, mind you!
Hmm. Maybe we're going to need 4.08.2.
The trouble with all this wondrous new GHC code is that one suspects that it has
Simon Peyton-Jones wrote:
Send us details about how to get access to your CVS archive,
plus instructions on how to build it, and we'll set it up.
Well you can read
http://www.informatik.uni-bremen.de/~ger/cvs/CVS.html
but (touch wood) the following should work
(bash is assumed)
(1)
Simon Marlow wrote:
[snip]
I stopped trying to compile GHC from CVS ages ago when I was
getting unexplained
core dumps which apparently could only be fixed by
reinstalling gcc/binutils . . .
And that's our fault?
[snip]
I've no idea whose fault it is. I think there are various
With ghc-4.08.1, running on Linux with -0 -O2-for-C, I get:
loop
With ghc-4.08, running on Solaris, with -O -O2-for-C, I get:
hsc: no threads to run: infinite loop or deadlock?
With ghc-4.08, running on Solaris, with -Onot, the compilation works.
For the sources you will need the whole of
Marcin 'Qrczak' Kowalczyk wrote:
[snip]
I am worried if the following scenario is possible: There are
two modules. Everything is OK. Now one of them adds an innocent
instance. It is perfectly correct in its context, but it happens that
it triggers an ambiguity in the second module. Still
When I compile the attached file on Linux with 4.08.1:
/home/ger/ghc-4.08.1-binary/bin/ghc -c Instances.hs -fglasgow-exts
-fallow-overlapping-instances -fallow-undecidable-instances
I get the message:
Instances.hs:1:
Duplicate or overlapping instance declarations
for `HasConfig
Keith Wansbrough wrote:
Instances.hs:1:
Duplicate or overlapping instance declarations
for `HasConfig (arcTypeConfig value) (arcTypeParms value)'
defined at Instances.hs:19 and defined at Instances.hs:11
This is not fair, because while the instances for
Keith Wansbrough wrote:
You can now see that the two instance declarations overlap: their
right hand sides are in fact *identical*. Remember that the
typechecker simply matches on the right-hand sides ("heads") of the
instance declarations.
No they do not overlap, unless there is
Marcin 'Qrczak' Kowalczyk wrote:
Wed, 18 Oct 2000 16:32:21 +0200, George Russell [EMAIL PROTECTED] pisze:
In a standalone GHC program, only the main thread is required to
terminate in order for the process to terminate.
I have a program (which does some fairly complex things
Marcin 'Qrczak' Kowalczyk wrote:
On Thu, 19 Oct 2000, George Russell wrote:
I don't see what this example has got to do with mine, since it prints
"Test completed" in the new process, while waiting in the old one.
I suspect that your program does the same thing. I.e. tha
I think I've narrowed the problem down a bit further. It looks as if the reason GHC is
hanging after the end of the main action is that there's a handle still open to a
socket
(to another process). If I hClose the handle explicitly before the end of the main
action,
the hClose action returns
In the GHC document, section "GHC-specific concurrency issues", it says:
In a standalone GHC program, only the main thread is required to
terminate in order for the process to terminate.
I have a program (which does some fairly complex things with forking processes,
calling sockets etcetera)
"Julian Seward (Intl Vendor)" wrote:
Sounds like some kind of rts/code generation bug. We fixed a
few in 4.08, so the recently released 4.08.1 might work better.
As usual the best thing you can do is send us a test case
showing the problem; can you do that?
Sadly not because this was at
Simon Marlow wrote:
I'm of the opinion that readFile/hGetContents are useful for small programs,
Personally I think Haskell would be a better language without them. But maybe
it's too late now . . .
Simon Marlow wrote:
Grrr. This works:
module Main (main) where
import IO
import Posix
import PosixUtil
import Concurrent
main = do
h - openFile "/tmp/fifo" ReadMode
fd - handleToFd h
threadWaitRead
Simon Marlow wrote:
I can't repeat this problem; on both Linux/x86 and Solaris/Sparc here the
Haskell process will block until another process opens the FIFO for writing,
and will return EOF after the writing process closes the FIFO. This appears
to be correct according to the POSIX spec.
Er what is going on here? CVS sources from this morning, building with
GHC binary release.
==fptools== gmake all --no-print-directory -r;
in /usr/local/pub-bkb/ghc/fptools/hslibs/tools/DrIFT
I think
test9: fatal error: resurrectThreads: thread blocked in a strange way
qualifies.
This is with a version of GHC downloaded and compiled in
the morning of 31st March. I'm attaching the HtmlFrame.hi/
HtmlFrame.hs; let me know if you want more. The .hi file
would have been generated with the same compiler options you
see here.
/usr/local/pub-bkb/ghc/ghc-latest/bin/ghc -c
George Russell wrote:
George Russell wrote:
I'm sure I've had problems with Sun's systime functions before . . .
../driver/ghc-inplace -I../includes -I. -Iparallel -optc-Wall -optc-W
-optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations
-optc-Winline -optc
George Russell wrote:
I'm sure I've had problems with Sun's systime functions before . . .
../driver/ghc-inplace -I../includes -I. -Iparallel -optc-Wall -optc-W
-optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations
-optc-Winline -optc-Waggregate-return -optc
==fptools== gmake boot --no-print-directory -r;
in /usr/local/pub-bkb/ghc/fptools/ghc/includes
gmake[2]: *** No rule to make target `Profiling.h', needed by `mkNativeHdr.o'. Stop.
gmake[1]: *** [boot] Error 1
gmake: ***
Simon Marlow wrote:
Yes, I removed Profiling.h from ghc/includes and added it to ghc/rts. You
might need to 'make boot'
Actually it was gmake boot that was falling over. However I seem to have
fixed that by doing "gmake depend" in ghc/includes (the .depend file contained
the obsolete
I'm sure I've had problems with Sun's systime functions before . . .
../driver/ghc-inplace -I../includes -I. -Iparallel -optc-Wall -optc-W
-optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations
-optc-Winline -optc-Waggregate-return -optc-Wpointer-arith
With GHC compiled from the night-before-last's CVS, compiling last-night's
CVS, I get
==fptools== gmake all --no-print-directory -r;
in /usr/local/pub-bkb/ghc/fptools/ghc/compiler
/usr/local/pub-bkb/ghc/ghc-latest/bin/ghc
I had this bug on Monday, but it's been fixed. Download the binary release
(4.06) and try again with the latest sources.
==fptools== gmake all --no-print-directory -r;
in /usr/local/pub-bkb/ghc/fptools/ghc/lib/std/cbits
../../../driver/ghc-inplace -O -I../../../includes -I../../../rts -Wall -static-c
system.c -o system.o
system.c:71:
Er, has this bug report been lost? It doesn't seem to have been dealt with . . .
George Russell wrote:
==fptools== gmake all --no-print-directory -r;
in /usr/local/pub-bkb/ghc/fptools/ghc/compiler
/usr/local/pub
Sven Panne wrote:
What GHC version are you using for compilation? Due to some library
reorganization you have to build 4.07 with 4.06, most of the 4.07
versions from CVS won't compile the current sources.
Ah I see. I was indeed building it from 4.07. I'll try going back to
4.06.
Oh, I forgot to say. This is compiling the latest (as of the weekend) GHC
with GHC compiled from CVS on 10th March.
Reuben Thomas wrote:
I already came across this, and Sigbjørn sent me a fix, which should soon
be in CVS. Just in case it's not, it follows below. I found that I also
needed to change rts/gmp/configure.in so that the first call to AC_INIT
occurred after the setting of the three variables
Simon Marlow wrote:
What version of autoconf is this, just out of interest?
autoconf --version
Autoconf version 2.13
Oh no, don't tell me I've got to install a private copy of yet another bit of
software to compile GHC . . .
Simon Marlow wrote:
It builds fine for me here with autoconf 2.13 on Solaris. Perhaps you have
some old configure files lying around in ghc/rts/gmp/*. Try blowing away
your gmp subtree and starting again.
After deleting the whole of ghc, rerunning autoconf several times
(why isn't this done
Reuben Thomas wrote:
I already came across this, and Sigbjørn sent me a fix, which should soon
be in CVS. Just in case it's not, it follows below. I found that I also
needed to change rts/gmp/configure.in so that the first call to AC_INIT
occurred after the setting of the three variables
causes the entire program to crash. (Not just the thread that is doing the
threadWaitRead.) Is this not a little drastic? To run the attached code use
ghc -syslib posix -syslib concurrent -cpp ThreadWaitFail.hs -o TWF
./TWF
ThreadWaitFail.hs
Marc van Dongen wrote:
Hi again,
When trying to build ghc from cvs (cvs update, make clean, etc)
I got:
==fptools== make all - --no-print-directory -r;
in /newdisk/dongen/cvs/fptools/ghc/compiler
1 - 100 of 155 matches
Mail list logo
