Re: Problem building on sparc/Linux
Something to do with Parsec, maybe? For what it's worth, the darcs repo version of genprimopcodes compiled with GHC 6.4 does parse the attached vore-primops.txt. On 3/1/06, Ian Lynagh [EMAIL PROTECTED] wrote: [ ... ] ../utils/genprimopcode/genprimopcode --data-decl prelude/primops.txt primop-data-decl.hs-incl genprimopcode: parse error at (line 579, column 1): unexpected \t expecting primop, section or thats_all_folks [ ... ] -- Cheers, Dinko ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 6.4.1 crash on Windows XP
Can you tell which process is crashing? Is it the GHC process that is interpreting Setup.hs, or the process invoked by Setup.hs to build the package? One thing you could try is compiling Setup.hs to a binary, and running that instead. Also, if you could run Setup like this and send us the output: $ ./setup build -v (or the runhaskell version, if that's the only one that crashes) Cheers, Simon On 28 February 2006 10:57, Cyril Schmidt wrote: Simon Marlow wrote: Does it always crash in the same way? Yes, as far as I can see. Unfortunately, most of the context is already lost when the error message pops up. The error code is always the same. Can you fire up GHCi and perform a small evaluation or two? Yes, this works just fine. Can you compile small programs, do they run? Also works fine. Please send us the complete output from commands that crash: eg. add -v to the build command above. I attach the stderr and stdout from runhaskell -v5 Setup.hs build I could also send the sources of the package being compiled, but I do not think they are relevant here: it crashes on *any* package. BTW, I had installed Cabal-1-1.3, but it did not help, so I reverted to the version of Cabal that came with the compiler. It is strange that the same version of GHC works fine on my PC and breaks on that of my colleague. To the best of my knowledge, these two PCs are not different from each other in any special way. I did have some strange crashes on my PC as well, but these were cured by upgrading from 6.4 to 6.4.1. Cheers, Cyril Cyril Schmidt wrote: A freshly installed GHC 6.4.1 on my colleague's PC crashes when I try to build a package: runhaskell Setup.hs build The effect is easily reproduceable (it shows up on *any* package that I try to build). Does anyone have any idea of what might be wrong here? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: factorial: let's get ahead of jhc! :)
FWIW, here's the inner loop of the accumulating parameter factorial compiled with yesterday's HEAD on x86_64, via C: Fac_zdwfac_info: movq%rsi, %rax testq %rsi, %rsi jne .L4 movq%rdi, %rbx jmp *(%rbp) .L4: leaq-1(%rsi), %rsi imulq %rax, %rdi jmp Fac_zdwfac_info It's not perfect, but note the absence of memory operations. The NCG version is similar, but has a couple of extra reg-to-reg moves (we need to beef up the NCG optimisations a bit). Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Missing Folder in ghc?
Ashley Yakeley wrote: Lemmih wrote: Did you run 'sh darcs-all get'? Oh, that wasn't in the README. Thanks. But now I get this: /usr/bin/ghc -H16m -O -I. -Iinclude -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp-c System/Directory/Internals.hs -o System/Directory/Internals.o -ohi System/Directory/Internals.hi System/Directory/Internals.hs:1:0: Module `System.Directory.Internals' is a member of package base-1.0. To compile this module, please use -ignore-package base-1.0. I'm using GHC 6.4. The configure script has mis-detected your GHC version somehow. Could you look through the output of configure, and see what it says about GHC? Also look in mk/config.mk, at the value of GhcCanonVersion. Maybe you switched GHC versions but didn't reconfigure? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem building on sparc/Linux
On Wed, Mar 01, 2006 at 12:24:17PM +, Simon Marlow wrote: There's a ticket open on this one: http://cvs.haskell.org/trac/ghc/ticket/470 The ticket does give more info (isSpace isn't working correctly). If you could track this down further, that would be great. Looks like a (fixed) gcc bug: [EMAIL PROTECTED]:/scratch/igloo/space$ rm *.o *.hi foo; ghc -Wall -O foo.hs -o foo ./foo [True,False,True,True,False,True] [EMAIL PROTECTED]:/scratch/igloo/space$ rm *.o *.hi foo; ghc -Wall -O foo.hs -o foo -pgmc /usr/bin/gcc-4.0 ./foo [True,True,True,True,True,True] [EMAIL PROTECTED]:/scratch/igloo/space$ gcc --version gcc (GCC) 3.3.6 (Debian 1:3.3.6-12) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [EMAIL PROTECTED]:/scratch/igloo/space$ /usr/bin/gcc-4.0 --version gcc-4.0 (GCC) 4.0.3 20060212 (prerelease) (Debian 4.0.2-9) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I'll get the default gcc upgraded and try the build again. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Building Win32 DLLs: Manual is not up-to-date
Michael Marte wrote: I am trying to turn a prototype written in Haskell into something I can call from a Visual Studio C++ 6.0 program. (The prototype is so clean and fast that there is no point in recoding everything.) So I followed the instructions in section 11.5 of the ghc manual (Building and using Win32 DLLs) and ended up as follows: $ ghc -c dllMain.c dllMain.c:4: warning: type defaults to `int' in declaration of `EXTFUN' dllMain.c:4: warning: parameter names (without types) in function declaration dllMain.c:4: warning: data definition has no type or storage class dllMain.c: In function `DllMain': dllMain.c:18: error: `__stginit_Adder' undeclared (first use in this function) dllMain.c:18: error: (Each undeclared identifier is reported only once dllMain.c:18: error: for each function it appears in.) Section 8.2 proposes to add extern void __stginit_Adder(void) which actually works. docs fixed, thanks. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem building on sparc/Linux
On Wed, 2006-03-01 at 12:59 +, Ian Lynagh wrote: On Wed, Mar 01, 2006 at 12:24:17PM +, Simon Marlow wrote: There's a ticket open on this one: http://cvs.haskell.org/trac/ghc/ticket/470 The ticket does give more info (isSpace isn't working correctly). If you could track this down further, that would be great. Looks like a (fixed) gcc bug: That might explain why it seems to be working perfectly well on Gentoo :-) We do a registerised sparc build and it builds itself and things like darcs gtk2hs ok. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem building on sparc/Linux
Ian Lynagh wrote: On Wed, Mar 01, 2006 at 12:24:17PM +, Simon Marlow wrote: There's a ticket open on this one: http://cvs.haskell.org/trac/ghc/ticket/470 The ticket does give more info (isSpace isn't working correctly). If you could track this down further, that would be great. Looks like a (fixed) gcc bug: [EMAIL PROTECTED]:/scratch/igloo/space$ rm *.o *.hi foo; ghc -Wall -O foo.hs -o foo ./foo [True,False,True,True,False,True] [EMAIL PROTECTED]:/scratch/igloo/space$ rm *.o *.hi foo; ghc -Wall -O foo.hs -o foo -pgmc /usr/bin/gcc-4.0 ./foo [True,True,True,True,True,True] [EMAIL PROTECTED]:/scratch/igloo/space$ gcc --version gcc (GCC) 3.3.6 (Debian 1:3.3.6-12) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [EMAIL PROTECTED]:/scratch/igloo/space$ /usr/bin/gcc-4.0 --version gcc-4.0 (GCC) 4.0.3 20060212 (prerelease) (Debian 4.0.2-9) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. It could be a gcc bug, or it could be that GHC is relying on undefined C semantics. If you feel inclined, I'd be really interested to know which code fragment is responsible (you'd need to replace fragments of the .s file in a binary search to find the right spot). If you can't be bothered, that's fine too :-) I'll close the bug. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 6.4.1 crash on Windows XP
Can you tell which process is crashing? Is it the GHC process that is interpreting Setup.hs, or the process invoked by Setup.hs to build the package? I suspect it is the GHC process that is invoked by Setup.hs, but I do not have any hard evidence to support this. One thing you could try is compiling Setup.hs to a binary, and running that instead. That worked! I think this counts as evidence for the above. Also, if you could run Setup like this and send us the output: $ ./setup build -v (or the runhaskell version, if that's the only one that crashes) I did it via runhaskell: runhaskell Setup.hs build -v Preprocessing library Vasicek-0.3... Building Vasicek-0.3... This is all what it said before the crash... Just about 15 minutes ago I fixed the problem (at least I hope I did) by installing the snapshot of GHC 6.4.2 of February 27 (BTW, the cc1.exe is missing from the tar file). I also found at least one difference between the PC where the problem showed up and the one where it did not. Both PCs had Cygwin installed. On the PC where the problem did not show up, the Cygwin executables shadowed the Windows programs with the same name: e.g. if I type 'find' in Windows command prompt, I get the UNIX find. On the PC where the problem did show up, it was the other way: I get the Windows find (of course, from the bash shell I always get the UNIX find). I do not know, though, if this is linked in any way to the GHC problem. I spent some time playing with PATH to try to make the two PCs behave the same, but I could not (I do not have Admin priviledges). The GHC was always started from the Windows prompt, never from bash. Anyway, as the problem is solved by moving from 6.4.1 to 6.4.2, we can conclude that it was caused by one of the bugs fixed after 6.4.1, and close the issue for now. If you, however, would like to continue investigation, please let me know -- I can easily reproduce the problem, and I'll be happy to get any extra information for you (once I know how to get it). I will keep version 6.4.1 for the time being. Thank you very much for the help. Cheers, Cyril ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
Hello *,
before filing a bug report, I want others to comment on my problem.
Maybe it's my fault, not ghc's.
I wrapped up some Haskell modules in a Win32 DLL.
Loading the DLL dynamically (with LoadLibrary) works fine. However,
whether I actually use the library or not, the program (an application
with MFC GUI) crashes upon termination.
To find the reason for the crash, I added a new function for unloading
the DLL using FreeLibrary. FreeLibrary works fine, however the program
crashes when it returns to the main event loop. Interestingly, when I
reload the library (FreeLibrary followed by LoadLibrary) the program
continues working. However, every reload cycle causes the virtual size
of the process to increase by about 300K and the fourth reload fails
with the error message getMBlock: VirtualAlloc failed with: 8 (appears
in a message window) accompanied by many repetitions of the message
Timer proc: wait failed -- error code: 6 (appears on stderr) and
followed by the message getMBlocks: misaligned block returned (again
in a message window). Then the programm crashes.
Development takes place on Windows XP Professional using MS Visual
Studio 6.0 SP 5 and ghc 6.4.1. There are no references from the C++ side
to the Haskell heap. I build the DLL using the command
ghc --mk-dll -optdll--def -optdllFoo.def -o Foo.dll Foo.o Foo_stub.o
dllMain.c
dllMain.c looks as follows:
#include windows.h
#include Rts.h
extern void __stginit_EUzu3820zu85(void);
static char* args[] = { ghcDll, NULL };
/* N.B. argv arrays must end with NULL */
BOOL
STDCALL
DllMain(HANDLE hModule, DWORD reason, void* reserved) {
if (reason == DLL_PROCESS_ATTACH) {
/* By now, the RTS DLL should have been hoisted in, but we need
to start it up. */
startupHaskell(1, args, __stginit_Foo);
return TRUE;
} else if (reason == DLL_PROCESS_DETACH) {
shutdownHaskell();
}
return TRUE;
}
I played around with hs_exit instead of shutdownHaskell, I moved
initialization and clean-up from DllMain to my library loader, nothing
helps. Even doing no clean-up whatsoever does not change the behaviour.
Any ideas?
Michael
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Missing Folder in ghc?
Simon Marlow wrote: The configure script has mis-detected your GHC version somehow. Could you look through the output of configure, and see what it says about GHC? Nothing special: checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu Canonicalised to: i386-unknown-linux checking for path to top of build tree... /home/ashley/Projects/Collected/Haskell/ghc checking for ghc... /usr/bin/ghc checking version of ghc... 6.4 checking for nhc... no checking for nhc98... no checking for hbc... no Also look in mk/config.mk, at the value of GhcCanonVersion. GHC = /usr/bin/ghc GhcDir = $(dir $(GHC)) GhcVersion = 6.4 GhcMajVersion = 6 GhcMinVersion = 4 GhcPatchLevel = 0 # Canonicalised ghc version number, used for easy (integer) version # comparisons. We must expand $(GhcMinVersion) to two digits by # adding a leading zero if necessary: ifneq $(findstring $(GhcMinVersion), 0 1 2 3 4 5 6 7 8 9) GhcCanonVersion = $(GhcMajVersion)0$(GhcMinVersion) else GhcCanonVersion = $(GhcMajVersion)$(GhcMinVersion) endif Maybe you switched GHC versions but didn't reconfigure? I think the problem is that I called autoconf etc. before I called darcs-all get, but not after. Calling autoreconf fixed the problem. -- Ashley Yakeley ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
