Sigbjorn writes:
Weird - are you sure it was capitalised as Haskell now prescribes?
Well, *that* makes me feel dumb. That was the problem, indeed. I ask
pardon for my blindness.
Dave Barton *
[EMAIL PROTECTED]
While running the new 4.02 on a Linux box, I got a "could not find
isAlphaNum" error. I looked at the .hi file, and it seemed OK;
however, switching to the definition of the expressions using
"isAlpha" and "isDigit" solved the problem. Don't know what's wrong,
but
Nah, not as long as I know about it. Thanks a million; I'll change
things as necessary.
Perhaps a line in the user's manual might help --- it wasn't clear to
me from reading it that modules that inherit non-standard modules must
also use the appropriate flags.
Come to think of it, this is the
Got a strange one. I am compiling two files using GHC, one of which
depends on the other. The first compiles just fine, but the second
compile gives an error on the *hi* file of the first. Specifically:
dlb@hudson temp]$ ghc -c -fallow-undecidable-instances -fglasgow-exts
Done; that did it.
Many, *many* thanks.
Once more, guided through the maze
Dave Barton *
[EMAIL PROTECTED] )0(
http://www.intermetrics.com/~dlb
Will do. I assume this does not require a recompile, just a reinstall?
Dave Barton *
[EMAIL PROTECTED] )0(
http://www.intermetrics.com/~dlb
OK, done. I have applied the patch, run gmake all, then gmake
install. I now get the following error from the final (ld) step:
/usr/src/ghc/lib/lib/libHSrts.a(Printer.o): In function `DEBUG_LoadSymbols':
/usr/src/ghc/fptools/ghc/rts/Printer.c:623: undefined reference to `bfd_init'
OK, I have compiled and installed ghc-4.00 on Linux Redhat 5.0. When
linking, inlcuding -syslip posix, I got the following ld error:
ld: cannot open -lnot-installed: No such file or directory
Obviously, not-installed is not mentioned in any of my command lines.
Any assistance would be
Working on a Linux Redhat 5.0 machine, running version 3.02 patchlevel
0, I have run across two problems:
1) A program that seems correct (at least, it compiles and runs under
Hugs) dies with a segmentation fault and dumps core.
2) Somehow, programs cannot find the Posix library. I am not
Sigbjorn writes:
Looks bad, could you tarzip the program up so that we can have a look
at it?
On the way to you, under separate cover (why burden the list?).
I don't know what might be causing this, could you provide the output
of compiling one such module with -v?
Found it (why
Consider the following (literate) program:
module Main where
import IO
main:: IO()
main = hSetBuffering stdin NoBuffering
interact trns
trns:: String - String
trns [] = []
trns (c:cs) =
let str c = case c of
'1' - "one\n"
'2' - "two\n"
Well, after keeping on going and getting a few more errors of the same
type, which I corrected without further guidance, I have gained two
things:
1) A much greater appreciation for the complexity of configuration
files and the messiness of Unix compatibility.
2) Gratitude to the Haskell
Having added the caddr_t definition to the two files, things chugged
along famously for a bit. However, down around absCSyn way, another
glitch occurred:
ghc -DOMIT_NATIVE_CODEGEN -cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen
-Iparser
Well, let me try to reply to both of these at once, just to keep
everyone up to date. Sven Panne writes:
Looks like an old friend of mine (problems on HP-UX some releases ago).
The problem is fptools/ghc/lib/cbits/timezone.h. It tries to be
clever about handling time info on different
Sigbjorn writes:
That is probably the simplest thing to do until we get a grasp on
changes made in the version of GNU libc2 that RH5.0 ships with. If
you're willing to experiment, doing
foo% cd ghc/lib
foo% make libHS.a required/Time_HC_OPTS=-optc-D__USE_BSD
may (or may
Oh, dear. This one I don't even know how to *start* with.
When compiling the library, the compile crashes with the following:
rm -f required/Time.o ; if [ ! -d required/Time ]; then mkdir required/Time; else
find required/Time -name '*.o' -print | xargs rm -f __rm_food ; fi ;
Simon Marlow writes:
1) The new library seems to use __USE_BSD rather than __FreeBSD__; I
had to change one "ifndef" to get it through "gmake boot".
Huh? Which library?
Just about all of them; hopping into /usr/include and doing a "grep
USE_BSD" gives a whole mess of files:
Sigh. I upgraded to Redhat 5.0 between GHC 2.10 and GHC 3.00.
Catastrophe!! Ah, well, I knew things had been going too well.
I fixed a couple of errors:
1) The new library seems to use __USE_BSD rather than __FreeBSD__; I
had to change one "ifndef" to get it through "gmake boot".
2) The
Something of little interest to most: rebuilding the Haskell 2.09 for
Linux worked fairly well. The only slow-up was the fairly frequent
necessity to allocate more heap for specific modules. A list of the
modules that failed, and the heap I had to allocate for them, is:
This isn't a bug; quite the opposite. But I've been so common here in
my comments and reports that I really must report success.
With the last release, GHC 2.07 fully self-compiles on a Linux box. I
first compiled it with 0.29 (as I have had to before), and then
compiled itself. Where it
Third in a series on the same set of files.
Thanks to Sigbjorn Finne's patch, the entire program now
compiles. However, the produced program now dies with a segmentation
fault. The text (which will probably help not one whit) occurs as
follows:
Segmentation fault caught, address = 38209318
IOT
I haven't had time to download his binary distribution and try to
recompile 2.04 yet. When I do, I'll let you know how it went.
Sometimes I just don't get the time to do the things I *want* to do.
Dave Barton *
22 matches
Mail list logo
