Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..?
Simon Marlow wrote: On 29/04/2009 01:23, Sigbjorn Finne wrote: Thanks Simon, sorry for not noticing your reply amidst the flow of g-h-b ticket reports before now. As there is no need to sail that close to the wind of playing with the delicate linking loading orders of the CRT and base DLLs like kernel32, my suggestion would be simply to avoid it. You don't do any explicit -lgcc -lc trickery when invoking gcc/ld on other platforms, so why be different? Apart from the changes to Win32.cabal and base.cabal mentioned in the original e-mail, injecting addDLL() calls for kernel32 and msvcrt in initLinker() ought to do it. I've now done exactly that. This seems like a good fix to try to get into 6.10.4 - can you think of any unexpected consequences? Cool, given that the RTS already has those two DLLs loaded repeated addDLL()s is fine (i.e., if other packages contain e.g., kernel32 uses), I can't think of any...other than possibly more contribs from people building on Windows ;-) If you feel the risk is not worth taking for 6.10.4, I'm totally fine with pushing it out. thanks, --sigbjorn ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..?
Thanks Simon, sorry for not noticing your reply amidst the flow of g-h-b ticket reports before now. As there is no need to sail that close to the wind of playing with the delicate linking loading orders of the CRT and base DLLs like kernel32, my suggestion would be simply to avoid it. You don't do any explicit -lgcc -lc trickery when invoking gcc/ld on other platforms, so why be different? Apart from the changes to Win32.cabal and base.cabal mentioned in the original e-mail, injecting addDLL() calls for kernel32 and msvcrt in initLinker() ought to do it. --sigbjorn On 4/27/2009 04:58, Simon Marlow wrote: On 24/04/2009 23:04, Sigbjorn Finne wrote: I've been experiencing repeated woes over the past 4-5 months when trying to spin up build trees on Windows with the new build system. This is happening on the 3-4 boxes that I regularly develop on, which leads me to believe that this may not be limited to just me.. The problem is that hsc2hs generated .c files (Foo_hsc_make.c) when compiled and linked via the 'ghc' that's configured against, will produce .exe's that crashes right out of the gates. gdb'ing the generated binaries, the crash is happening in the CRT startup code with some further poking around I've been able to determine that it is the explicit presence of -l options for 'kernel32' and 'msvcrt' when linking that's the cause. This is with a variety of versions of 'ld' and binutils snapshots (2.17.x -- 2.19). Using the 2.19.1 version that ships with gcc4.3.3 snapshots for mingw is well-behaved, but ghc is still using gcc-3.4.5. We have seen this problem here on Satnam Singh's machine, but we eventually put it down to a conflict between versions of certain MSYS bits. There may indeed be a real problem here, I don't know. On Satnam's machine we established that the problem was provoked by updating binutils, and the solution was don't do that (Satnam had originally done this because the windres that comes with MSYS was incompatible with GHC, but that can be worked around by just copying in a suitable windres). We also tracked it down as far as compiling a trivial C program with -lmsvcrt. Incedentally if you follow the instructions on the wiki exactly, you won't run into this problem: http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows. There's a couple of things that are odd here: * base.cabal files have kernel32 and msvcrt as extra-libraries. This is clearly not required when doing invocations via ld(1), and causes considerable mischief, so it'd be good if there was a way in .cabal files to distinguish between stuff that goes into 'extraLibraries' and 'extraGHCiLibraries' in package.conf's InstalledPackageInfos. (Is there? Couldn't locate anything appropriate while working with the Cabal sources..) * 'base' needing to include these two dependencies even for GHCi usage. A running RTS will have these loaded already, so it really ought to have primed the list of opened DLLs by explicitly loading them upon initialization of the linker. [I've got a trivial patch against rts/Linker.c that does this; can forward/commit if of interest..] I've no idea why these library dependencies are there. It might well be historical. I'm happy to defer to Windows experts such as yourself on whether we should have them or not (I guess not?). * In addition to the patch referred to above, to solve these problems, I had to scrub libraries/base/base.cabal of 'kernel32' and 'msvcrt' + the package.conf's for the versions of ghc I'm building against had to be edited, limiting the use of 'kernel32' and 'msvcrt' to extraGHCiLibraries for both the 'base' and 'Win32' packages. Long and rambling..hope you made it this far ;-) Is anyone else running into this issue should we do something about it? If not, details of compilation environment that you've got that avoids running into this issue would be most welcome. It's a bit of a chore spinning up new builds, as is. One open question is whether we should expect gcc foo.c -lmsvcrt to work. It works with older versions of MSYS/mingw, but apparently not with more recent versions. On the face of it this seems like it ought to be harmless, since msvcrt will eventually be linked in anyway. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..?
On 4/25/2009 05:37, Ian Lynagh wrote: Hi Sigbjorn, On Fri, Apr 24, 2009 at 03:04:14PM -0700, Sigbjorn Finne wrote: I've been experiencing repeated woes over the past 4-5 months when trying to spin up build trees on Windows with the new build system. By new build system do you mean http://darcs.haskell.org/ghc-new-build-system/ ? Hi Ian, young and old. The above one + ones using the older (git darcs versions) The problem is that hsc2hs generated .c files (Foo_hsc_make.c) when compiled and linked via the 'ghc' that's configured against, will produce .exe's that crashes right out of the gates. Do you mean that building GHC fails, or that building other things using the built GHC fails? If the latter, can you give a testcase please? Right, when building the repo contents. Any .hsc that's in the tree elicits a hard crash (i.e., dialog box pops up reporting the failure of any *_hsc_make.exe ) This is when building with 6.10.1, but that's not the real cause here. If I don't take the evasive action (as outlined in the original e-mail), the resulting stage1/stage2 ghc installs will fail also (provided I've manually guided the build process past these crashes to reach completion first, of course.) hth --sigbjorn ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..?
Oh, and a simple test case:
foo$ cat a.c
int main() { return 0; }
foo$ c:/ghc/ghc-6.10.1/gcc -o a a.c
foo$ ./a ; echo $?
0
foo$ c:/ghc/ghc-6.10.1/gcc -o a a.c -lkernel32
foo$ ./a ; echo $?
0
foo$ c:/ghc/ghc-6.10.1/gcc -o a a.c -lkernel32 -lmsvcrt
foo$ ./a ; echo $?
crash-reporting dialog box shows up
5
foo$
--sigbjorn
On 4/25/2009 11:38, Sigbjorn Finne wrote:
On 4/25/2009 05:37, Ian Lynagh wrote:
Hi Sigbjorn,
On Fri, Apr 24, 2009 at 03:04:14PM -0700, Sigbjorn Finne wrote:
I've been experiencing repeated woes over the past 4-5 months
when trying to spin up build trees on Windows with the new build
system.
By new build system do you mean
http://darcs.haskell.org/ghc-new-build-system/
?
Hi Ian,
young and old. The above one + ones using the older (git darcs
versions)
The problem is that hsc2hs generated .c files (Foo_hsc_make.c) when
compiled and linked via the 'ghc' that's configured against, will
produce
.exe's that crashes right out of the gates.
Do you mean that building GHC fails, or that building other things using
the built GHC fails? If the latter, can you give a testcase please?
Right, when building the repo contents. Any .hsc that's in the tree
elicits a hard crash (i.e.,
dialog box pops up reporting the failure of any *_hsc_make.exe ) This
is when building with
6.10.1, but that's not the real cause here.
If I don't take the evasive action (as outlined in the original
e-mail), the resulting stage1/stage2
ghc installs will fail also (provided I've manually guided the build
process past these crashes
to reach completion first, of course.)
hth
--sigbjorn
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Linking hsc2hs .c output on Windows w/ build system: is it just me..?
Hi, I've been experiencing repeated woes over the past 4-5 months when trying to spin up build trees on Windows with the new build system. This is happening on the 3-4 boxes that I regularly develop on, which leads me to believe that this may not be limited to just me.. The problem is that hsc2hs generated .c files (Foo_hsc_make.c) when compiled and linked via the 'ghc' that's configured against, will produce .exe's that crashes right out of the gates. gdb'ing the generated binaries, the crash is happening in the CRT startup code with some further poking around I've been able to determine that it is the explicit presence of -l options for 'kernel32' and 'msvcrt' when linking that's the cause. This is with a variety of versions of 'ld' and binutils snapshots (2.17.x -- 2.19). Using the 2.19.1 version that ships with gcc4.3.3 snapshots for mingw is well-behaved, but ghc is still using gcc-3.4.5. There's a couple of things that are odd here: * base.cabal files have kernel32 and msvcrt as extra-libraries. This is clearly not required when doing invocations via ld(1), and causes considerable mischief, so it'd be good if there was a way in .cabal files to distinguish between stuff that goes into 'extraLibraries' and 'extraGHCiLibraries' in package.conf's InstalledPackageInfos. (Is there? Couldn't locate anything appropriate while working with the Cabal sources..) * 'base' needing to include these two dependencies even for GHCi usage. A running RTS will have these loaded already, so it really ought to have primed the list of opened DLLs by explicitly loading them upon initialization of the linker. [I've got a trivial patch against rts/Linker.c that does this; can forward/commit if of interest..] * In addition to the patch referred to above, to solve these problems, I had to scrub libraries/base/base.cabal of 'kernel32' and 'msvcrt' + the package.conf's for the versions of ghc I'm building against had to be edited, limiting the use of 'kernel32' and 'msvcrt' to extraGHCiLibraries for both the 'base' and 'Win32' packages. Long and rambling..hope you made it this far ;-) Is anyone else running into this issue should we do something about it? If not, details of compilation environment that you've got that avoids running into this issue would be most welcome. It's a bit of a chore spinning up new builds, as is. thanks --sigbjorn ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1196: Cabal on Windows doesn't like the in-place GHCs
I added support for generating .bat files (to HEAD, I believe) for these
in-place
wrappers some time ago just to address this issue, so you may want to
look into
dragging those Makefile mods over.
--sigbjorn
On 3/5/2007 08:58, GHC wrote:
#1196: Cabal on Windows doesn't like the in-place GHCs
-+--
Reporter: igloo | Owner:
Type: bug | Status: new
Priority: normal| Milestone: _|_
Component: Compiler | Version: 6.6
Severity: normal|Keywords:
Difficulty: Unknown |Testcase: cabal01
Architecture: Unknown | Os: Windows
-+--
From e.g. a cmd prompt, Windows doesn't like the in-place GHCs:
{{{
C:\C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-inplace
'C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-inplace' is
not recognized as an internal or external command, operable program or
batch file.
C:\cat C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-
inplace
#!/bin/sh
exec C:/cygwin/home/ian/ghc/6.6-branch/build/compiler/stage2/ghc
-BC:cygwinhomeianghc6.6-branchbuild $@
}}}
which means the cabal01 test fails thus:
{{{
$ ./setup configure --prefix=`pwd`/install --with-
compiler=C:/cygwin/home/ian/ghc/6.6-branch/build/compiler/stage1/ghc-
inplace --with-hc-pkg=../../../../../utils/ghc-pkg/ghc-pkg-inplace
--enable-library-profiling
setup.exe: Warning: Package is copyright All Rights Reserved
setup.exe: Warning: No license-file field.
'C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage1\ghc-inplace' is
not recognized as an internal or external command,
operable program or batch file.
Configuring test-1.0...
}}}
(the odd output order is due to buffering)
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1196: Cabal on Windows doesn't like the in-place GHCs
If you're referring to ghc-pkg-inplace invocations from Cabal, the
same hack was applied in utils/ghc-pkg also.
--sigbjorn
On 3/6/2007 08:46, Simon Marlow wrote:
Ah, so you did, thanks for reminding me. We still need to do
something about ghc-pkg, though.
Cheers,
Simon
Sigbjorn Finne wrote:
I added support for generating .bat files (to HEAD, I believe) for
these in-place
wrappers some time ago just to address this issue, so you may want to
look into
dragging those Makefile mods over.
--sigbjorn
On 3/5/2007 08:58, GHC wrote:
#1196: Cabal on Windows doesn't like the in-place GHCs
-+--
Reporter: igloo | Owner: Type:
bug | Status: newPriority: normal|
Milestone: _|_ Component: Compiler | Version:
6.6Severity: normal|Keywords:
Difficulty: Unknown |Testcase: cabal01
Architecture: Unknown | Os: Windows
-+--
From e.g. a cmd prompt, Windows doesn't like the in-place GHCs:
{{{
C:\C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-inplace
'C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-inplace'
is
not recognized as an internal or external command, operable program or
batch file.
C:\cat C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-
inplace
#!/bin/sh
exec C:/cygwin/home/ian/ghc/6.6-branch/build/compiler/stage2/ghc
-BC:cygwinhomeianghc6.6-branchbuild $@
}}}
which means the cabal01 test fails thus:
{{{
$ ./setup configure --prefix=`pwd`/install --with-
compiler=C:/cygwin/home/ian/ghc/6.6-branch/build/compiler/stage1/ghc-
inplace --with-hc-pkg=../../../../../utils/ghc-pkg/ghc-pkg-inplace
--enable-library-profiling
setup.exe: Warning: Package is copyright All Rights Reserved
setup.exe: Warning: No license-file field.
'C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage1\ghc-inplace'
is
not recognized as an internal or external command,
operable program or batch file.
Configuring test-1.0...
}}}
(the odd output order is due to buffering)
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #942: Windows programs throw uncaught Invalid HANDLE exception on exit
[Due to a somewhat inconvenient HD meltdown some weeks ago, I lost a bunch of data/user settings amongst other things, including the password to GHC's Trac, hence this lame response directly to the mailing list] I fixed this one a week or two ago on the 6.6 branch -- http://www.haskell.org/pipermail/cvs-ghc/2006-October/032154.html Have not had the timespace to drag it over to HEAD since then. hth --sigbjorn GHC wrote: #942: Windows programs throw uncaught Invalid HANDLE exception on exit +--- Reporter: [EMAIL PROTECTED] | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Runtime System |Version: 6.6 Severity: major | Resolution: Keywords: uncaught exception HANDLE exit | Difficulty: Unknown Testcase: N/A | Architecture: x86 Os: Windows | +--- Changes (by [EMAIL PROTECTED]): * severity: normal = major Comment: I've changed the severity to major because I feel this bug prevents me distributing any binaries compiled under ghc6.6 for Windows, since whether or not the bug is visible (ie if you choose to run the binary under a debugger), obviously something is very wrong indeed with the runtime or else it wouldn't be trying to use an invalid handle (or cause one of the windows DLLs to do so) at program exit. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #942: Windows programs throw uncaught Invalid HANDLE exception on exit
Ought to (but don't sue me if it doesn't.) --sigbjorn Bulat Ziganshin wrote: Hello Sigbjorn, Tuesday, October 31, 2006, 10:04:52 PM, you wrote: is that means that current 6.6 precompiled snapshots like http://www.haskell.org/ghc/dist/stable/dist/ghc-6.6.20061031-i386-unknown-mingw32.tar.gz should work fine? this problem is very important for me too ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc-6.6 on Windows Vista: cannot exec as
Thank you, something's changed wrt path handling it seems. A temporary fix/workaround (as reported by other Vista users) is to add the ghc-6.6\gcc-lib directory to your PATH. If you have the time, here's a couple of things to try out to diagnose the problem further: c:\foo echo int x = 22; foo.c c:\foo c:\ghc\ghc-6.6\gcc -Bc:\ghc\ghc-6.6\gcc-lib/ -c foo.c ... # expected to fail (same as ghc's invoc of gcc below) c:\foo c:\ghc\ghc-6.6\gcc -Bc:\ghc\ghc-6.6\gcc-lib -c foo.c ... # what happens here? c:\foo c:\ghc\ghc-6.6\gcc -Bc:\ghc\ghc-6.6\gcc-lib\ -c foo.c ... # what happens here? --sigbjorn Satnam Singh wrote: The -v output below. I shall try it with Vista RC2 and see if that make a difference. The same installer file on Windows XP and Windows Server seems to work fine. Cheers, Satnam C:\sd\satnams\haskell\helloghc Hello.hs gcc: installation problem, cannot exec `as': No such file or directory C:\sd\satnams\haskell\helloghc -v Hello.hs Glasgow Haskell Compiler, Version 6.6, for Haskell 98, compiled by GHC version 6.6 Using package config file: c:\ghc\ghc-6.6\package.conf wired-in package base mapped to base-2.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0 wired-in package template-haskell mapped to template-haskell-2.0 Hsc static flags: -static Created temporary directory: C:/Users/satnams/AppData/Local/Temp/ghc5440_0 *** Checking old interface for main:Main: *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 10 *** Simplify: Result size = 8 *** Tidy Core: Result size = 8 *** CorePrep: Result size = 10 *** Stg2Stg: *** CodeGen: *** CodeOutput: *** Assembler: c:\ghc\ghc-6.6\gcc -Bc:\ghc\ghc-6.6\gcc-lib/ -I. -c C:\Users\satnams\AppData\Local\Temp\ghc5440_0\ghc5440_0.s -o Hello.o gcc: installation problem, cannot exec `as': No such file or directory *** Deleting temp files: Deleting: C:/Users/satnams/AppData/Local/Temp/ghc5440_0/ghc5440_0.s *** Deleting temp dirs: Deleting: C:/Users/satnams/AppData/Local/Temp/ghc5440_0 C:\sd\satnams\haskell\hello -Original Message- From: Sigbjorn Finne [mailto:[EMAIL PROTECTED] Sent: 18 October 2006 14:03 To: Satnam Singh Cc: GHC-bugs list Subject: Re: ghc-6.6 on Windows Vista: cannot exec as Thanks; for people that don't have access to Vista, the output resulting from 'ghc -v Hello.hs' would help narrowing this down a bit...I hope. --sigbjorn Satnam Singh wrote: I just installed GHC-6.6. on Windows Vista RC1 (using the MSI installer) but when I compile I get the error: c:\sd\satnams\haskell\helloghc Hello.hs gcc: installation problem, cannot exec `as': No such file or directory Has anyone else noticed this? And before anyone tells me to: no, I can't use Linux! Cheers, Satnam ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc-6.6 on Windows Vista: cannot exec as
Thanks; for people that don't have access to Vista, the output resulting from 'ghc -v Hello.hs' would help narrowing this down a bit...I hope. --sigbjorn Satnam Singh wrote: I just installed GHC-6.6. on Windows Vista RC1 (using the MSI installer) but when I compile I get the error: c:\sd\satnams\haskell\helloghc Hello.hs gcc: installation problem, cannot exec `as': No such file or directory Has anyone else noticed this? And before anyone tells me to: no, I can’t use Linux! Cheers, Satnam Satnam Singh Microsoft 7 JJ Thomson Avenue Cambridge CB3 0FB United Kingdom Email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] UK tel: +44 1223 479905 US tel: +1 206 219 9024 Fax: +44 1223 479 999 UK cell: +44 7979 648412 URL: http://research.microsoft.com/~satnams http://research.microsoft.com/%7Esatnams MSN IM: [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #891: hsc2hs tries to remove an open file
This is a long standing, irksome Win32 timing issue, and is not GC related (AFAICR, it was reproducible in straight C code). A better workaround, which was experimented with in STABLE at some point, is to simply delay the clean up of the files until the end of hsc2hs's run --sigbjorn GHC wrote: #891: hsc2hs tries to remove an open file -+-- Reporter: eivuokko |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 6.4.2 Severity: normal| Keywords: Os: Windows | Difficulty: Unknown Architecture: Unknown | -+-- hsc2hs sometimes fails with error Permission denied in Windows. This is because it tries to remove a file it has open handle to. The error usually repeats per-machine and file, but what file and machine it shows up with, is random. As a workaround, calls to removeFile can be removed, or exceptions catched. From a mail by Brian Smith: http://www.haskell.org/pipermail/cvs-ghc/2006-September/031186.html ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #882: Overflow bug in System.Time
The fix is trivial though (and have been applied to HEAD) --
http://hackage.haskell.org/trac/ghc/ticket/588
--sigbjorn
GHC wrote:
#882: Overflow bug in System.Time
---+
Reporter: simonpj |Owner:
Type: bug | Status: new
Priority: normal |Milestone:
Component: libraries/base | Version: 6.4.2
Severity: normal | Keywords:
Os: Unknown | Difficulty: Unknown
Architecture: Unknown |
---+
Frederik Eaton reports: The Glorious Glasgow Haskell Compilation System,
version 6.4.3.20060816
{{{
now - getClockTime
addToClockTime (TimeDiff {tdYear = 0, tdMonth = 0, tdDay = 0, tdHour =
0, tdMin = 0, tdSec = 0, tdPicosec = }) now
*** Exception: Time.toClockTime: picoseconds out of range
}}}
This is clearly a bug. Simon Marlow comments: System.Time is kind-of
deprecated: the new time package is intended to supercede it, but I have
been reluctant to really deprecate System.Time because it comes from
Haskell98, and also because we don't have much experience with its
replacement.
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #840: GHC on loosing its handles takes 100% CPU
But as long as it's Haskell code consuming all those CPU cycles, it can't be all bad? :) If any of you are running into this while invoking ghci.exe, you may want to play with using ghc.exe --interactive instead to see if that improves matters. Not using ghci.exe avoids a layer of sub-process'ery and console event handling nonsense; a culprit, perhaps? --sigbjorn - Original Message - From: Lennart Augustsson [EMAIL PROTECTED] To: Bulat Ziganshin [EMAIL PROTECTED] Cc: GHC [EMAIL PROTECTED]; glasgow-haskell-bugs@haskell.org Sent: Friday, August 04, 2006 05:46 Subject: Re: [GHC] #840: GHC on loosing its handles takes 100% CPU It happens all the time to me that GHC doesn't die properly on windows. Every so often I have to kill a few straggling ghc processes. They all spin consuming 100% CPU when this happens. -- Lennart On Aug 2, 2006, at 10:09 , Bulat Ziganshin wrote: Hello GHC, Wednesday, August 2, 2006, 4:33:09 PM, you wrote: #840: GHC on loosing its handles takes 100% CPU import System.Process main = runInteractiveCommand ghc When run terminates immediately, as expected, but leaves an instance of ghc running. The ghc process takes up 100% of the CPU time, and seemingly does nothing. well, i have similar problem: there are only 256 megs on my machine and sometimes when ghc compilation uses more than 200 megs and starts trashing memory, i tries to stop it by hitting Ctrl-C. in this situation it's rather typical that i got back my console (and rerun ghc) but old GHC process don't killed and continue to compile program. i can investigate it further but don't know what to do. at least it seems that memory trashing is required to uncover this problem. i also should note that i run ghc --make from the .cmd file so there is a whole stack of processes runned. may be i just kill higher-level ghc (or even cmd) and lower-level ghc still continue to do it's job? i'm not sure.. -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Strange behaviour with classes (both Hugs and GHC)
Hi,
if you desugar the definition that's causing the type error,
perhaps it becomes a little bit clearer what's going on, i.e.,
from
problematic :: MyAnnotatedType Int
problematic = defaultVal{theInt=42,theAnnotation=10}
you expand this to
problematic' = case defaultVal of { MAT a b c - MAT 42 b 10 }
Clearly, the type of 'c' is ambiguous here. Interestingly, if Haskell 98
had defined record update expr e{fields} as having the same type
as e, this wouldn't have been an issue:
no_probs =
case defaultVal of { m@(MAT a b c) - (MAT 42 b 10) `asTypeOf` m}
hth
--sigbjorn
- Original Message -
From: Magnus Björk [EMAIL PROTECTED]
To: glasgow-haskell-bugs@haskell.org; hugs-bugs@haskell.org
Sent: Monday, May 29, 2006 03:34
Subject: Strange behaviour with classes (both Hugs and GHC)
I just ran into a strange behaviour of both Hugs and GHC. I discussed it
with John Hughes who managed to find a workaround, and suggested that I
ask you whether this is really expected behaviour.
The attached file contains a small example that exhibits the problem.
--
/MpB
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bug in cvs head ghci
Yep, reproducible with last night's HEAD build on mingw (but not STABLE.) --sigbjorn - Original Message - From: Simon Peyton-Jones [EMAIL PROTECTED] To: wld [EMAIL PROTECTED]; glasgow-haskell-bugs@haskell.org Sent: Friday, December 16, 2005 08:13 Subject: RE: Bug in cvs head ghci Strange. This does not happen for me on Linux or Windows (GHc 6.4.1). Has anyone else seen it? Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of wld | Sent: 08 December 2005 13:25 | To: glasgow-haskell-bugs@haskell.org | Subject: Bug in cvs head ghci | | HI, | | Typing |Prelude :b GHC.Base | | I get | [snip] | data Addr# | data Array# a | data Bool = False | True | data ByteArray# | data Char# | data Char = C# Char# | data Double# | data Float#*** Exception: No match in record selector TyCon.tyConTyVars | Prelude | | ghc built on Linux with | - ghc 6.4.1 | - gcc 4.0.2 | | -- | V.Rudenko ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: cc1plus.exe not included in Win32 distro
It was intentionally removed (the intention being to remove heft from the installer) after it had been unintentionally included for quite a while. The rule has always been that only tools that GHC depends upon to operate are bundled with it on the mingw side -- the only exception to that rule has been the recent inclusion of 'ar'. Should GHC binary dists include a C++ compiler? I'd say no, but if there are practical and compelling reasons to do so, it's no big deal to re-include the binary. --sigbjorn - Original Message - From: Bulat Ziganshin [EMAIL PROTECTED] To: glasgow-haskell-bugs@haskell.org Sent: Friday, October 14, 2005 10:49 Subject: cc1plus.exe not included in Win32 distro Hello all, the official Win32 distro (http://www.haskell.org/ghc/dist/6.4.1/ghc-6-4-1.msi) does not contain cc1plus.exe, needed to compile CPP files: C:\FreeArchiver ghc a.cpp gcc: installation problem, cannot exec `cc1plus': No such file or directory is this a packaging bug or intentional change? -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Network Exception
Just to be clear -- this is with ghc-6.4.1 as distributed via the GHC web pages and not some local build..? I can't explain this -- the example code you give will have successfully started up WinSock (version 1.1) prior to calling getHostName, so that error condition doesn't make much sense. Given the two networking issues you've already come across, I wouldn't discount the option that this might be due to a local problem with your networking setup (WinSock proxy config..?) --sigbjorn - Original Message - From: Arias [EMAIL PROTECTED] To: Sigbjorn Finne [EMAIL PROTECTED] Cc: glasgow-haskell-bugs@haskell.org Sent: Friday, October 14, 2005 14:01 Subject: Re: Network Exception Thanks for the reply. I don't know if the problem is the same, but when I try to run this code: main = withSocketsDo $ do host - getHostName putStrLn host the getHostName throws this exception: getHostName: failed (Successful WSAStartup not yet performed (WSANOTINITIALISED)) :( I'm using Windows XP Professional Sigbjorn Finne escribió: Hi, that error message is a bit confusing, to say the least: getProtocolByName identifies itself as getServiceEntry when failing. In this case, I'm quite sure, your snippet fails because (getProtocolByName tcp) isn't successful. I've no idea why your /etc/protocols doesn't contain an entry for 'tcp'. The error message in said function has now been fixed; thanks for the report. --sigbjorn - Original Message - From: Arias [EMAIL PROTECTED] To: glasgow-haskell-users@haskell.org Sent: Friday, October 14, 2005 06:47 Subject: Network Exception Hi, I've a problem, I'm using this code on GHC compiler version 6.4.1: --- BEGIN --- module Main where import System.IO import Network main = withSocketsDo $ do handle - connectTo localhost ( PortNumber 8080 ) hSetBuffering handle LineBuffering hClose handle --- END --- The problems is that it throws an exception at connectTo, the exception is: getServiceEntry: does not exist (no such service entry) The server and the port is correct, I have apache listening on port 8080 and if I put http://localhost:8080/ on browser it loads a web page. Do somebody knows what it happens and how to fix it? thanks. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Fw: 6.4.1 win32 candidate installer
FYI - widening the (testing) audience a bit. --sigbjorn - Original Message - From: Sigbjorn Finne [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, August 22, 2005 13:59 Subject: 6.4.1 win32 candidate installer With 6.4.1 being close to done, I've rolled an MSI test installer of the bits -- available as http://www.haskell.org/ghc/dist/stable/dist/ghc-6-4-1-20050822.msi Reports of installer snafus or any other problems using it are most welcome. thanks --sigbjorn ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Undefined symbols on new install of ghc 6.2.2
Can't think of a reasonable explanation for the behaviour you're seeing, I'm afraid. If you look at the undefined symbols from the link, _ZCMain_main_closure isn't being found -- it should be in Build.o, which is included on the command line. The weird thing is that the linker does report undefined symbols from that closure's entry point, _ZCMain_main_entry (in Build.o), but fails to see the (.data) symbol for the closure itself. On the off-chance you haven't tried this already, could you try to delete the object files and re-do the --make? Add -fvia-C while you're at it. If you want to examine what the linker actually slurps in, try -optl-Wl,--verbose GHC binary installs on Windows are islands as far as tools needed to compilelink Haskell code goes. You may run into trouble if you compile a .c file with a local installation of gcc and then try to link the object file with ghc, but I don't think that's the case here. --sigbjorn - Original Message - From: Alastair Reid [EMAIL PROTECTED] To: Sigbjorn Finne [EMAIL PROTECTED] Cc: glasgow-haskell-bugs@haskell.org Sent: Monday, August 22, 2005 06:16 Subject: RE: Undefined symbols on new install of ghc 6.2.2 Thanks Sigbjorn, Chris gave these a shot and everything looks right. (i.e., the symbols exist, tmpdir is big and changing it doesn't help and invoking ghc on the .o files directly doesn't help.) Also, building with the latest release of ghc works fine. (This is slightly tedious because we need both 6.2.2 and 6.4 at the moment but we'll probably update our code to work with 6.4 sometime soon anyway.) One interesting detail was that the .a file has names with triple-underscore prefixes but the linker error messages have single-underscore prefixes. Is this just the linker deleting _'s when displaying error messages or is this the real problem? I'm not sure what Chris has installed on his machine but is it possible that if he had cygwin (say) installed the gcc from that install would be used instead of the one that comes in the ghc package? -- Alastair Reid, Principal Engineer, RD ARM Ltd, 110 Fulbourn Rd, Cambridge, CB1 9NJ. T: +44 1223 406 109 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Undefined symbols on new install of ghc 6.2.2
Puzzling; couple of things to check for: - nm -o c:/ghc/ghc-6.2.2/libHSbase.a | grep 'T ___stginit_Prelude' is successful. - the TMPDIR setting appears to be w:/tmp -- make sure that actually exists isn't clogged up. Does changing it to . (or somesuch) alter the behaviour? - does an invocation of the form ghc -o build.exe MakeUtils.o Build.o whatever else succeed? --sigbjorn - Original Message - From: Alastair Reid [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, August 17, 2005 05:59 Subject: Undefined symbols on new install of ghc 6.2.2 One of my colleagues just installed ghc 6.2.2 on their Windows machine. GHC compiles fine but ghc --make fails at the linking stage with a bunch of undefined symbols that ought to have been part of the ghc install like: ./MakeUtils.o(.text+0x43): In function `_stginit_MakeUtils_': : undefined reference to `_stginit_IO_' ./MakeUtils.o(.text+0x4d): In function `_stginit_MakeUtils_': : undefined reference to `_stginit_Prelude_' ./MakeUtils.o(.text+0x5c): In function `r1pU_srt': : undefined reference to `GHCziBase_zdfEqZMZN_closure' (see attached file for complete list of undefined symbols). We've checked that the lib files exist and confirmed that he installed ghc in the normal place (see message at end of this message). ghc-6.2.2 works just fine on my machine. Does this ring any bells for anyone? -- Alastair Reid, Principal Engineer, RD ARM Ltd, 110 Fulbourn Rd, Cambridge, CB1 9NJ. T: +44 1223 406 109 yadda yadda -Original Message- Alastair Reid wrote: Can you try: ghc -v this will produce a few hundred lines of output amongst which there's a bunch of filenames like c:/ghc/ghc-6.2.2 c:/ghc/ghc-6.2.2/imports c:/ghc/ghc-6.2.2/hslibs-imports/util The first should have a bunch of files with names like libHS*.a and is the most important The latter should have a bunch of *.hi files (and seem to be fine since you got as far as linking). Assuming you mean that these directories should have the files you name (not the output of ghc -v), then, yes, they are present. Check you're not really low on diskspace in case the install silently failed (e.g., the 100s of Mbytes of libHS*.a files weren't all installed). Plenty of disc space. If that looks plausible, try adding the -v flag to the ghc --make command line to see if you get any useful info about the failure. If still nothing, try -v4 and -v5 to get extra verbosity. I tried this but learnt nothing new (see attached). Is it possible that I need to set some environment variables other than PATH (e.g. LD_LIBRARY_PATH)? ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: stdin set to nonblocking mode
Simon Marlow [EMAIL PROTECTED] writes: ... No - read() can always return less than the requested amount of data, even when not in O_NONBLOCK mode. Hmm, care to give some details as to why you equate can with always will on all platforms? --sigbjorn ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: stdin set to nonblocking mode
Simon Marlow [EMAIL PROTECTED] writes: On 11 August 2005 01:18, John Meacham wrote: Why do we set file descriptors to nonblocking mode anyway if they are waited on by a select. there shouldn't be a need to use both It avoids an extra system call per read(), i.e. a single read() instead of select() + read(). And there's a slight chance of a race between the select() and read() calls, if some other thread or process is reading from the same descriptor. With non-blocking read(), this isn't an issue. The overhead of the extra syscall is probably a non-issue, but the race is mildly worrying. The main reason for using non-blocking descriptors is that select() only tells you that I/O is possible over a descriptor, not the amount. Hence block read()s and writes() run the real risk of blocking the whole system. Insisting on single byte read()/write()s is not an option ;-) --sigbjorn ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: getDirectoryContents fails in GHC 6.5 snapshots, works in GHC 6.4.1 snapshots
Mystery now solved (*), nightly builds should now behave a bit better
when it comes to directory handling.
--sigbjorn
* - gcc-3.4.* mingw builds hard-codes default include search paths
referring to /mingw/. My local box happened to contain an older mingw
dist in that location, leading to confusion about the layout of 'struct
dirent'.
- Original Message -
From: Sigbjorn Finne [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: glasgow-haskell-bugs@haskell.org
Sent: Monday, August 08, 2005 10:38
Subject: Re: getDirectoryContents fails in GHC 6.5 snapshots,works in GHC
6.4.1 snapshots
I can repro it too. Looks as if the dirent.h implementation of the
mingw snapshot that the nightlies are using is spongled. Simple
stuff like
#include stdio.h
#include errno.h
#include dirent.h
int main()
{
DIR* dp;
struct dirent* de;
dp = opendir(c:\\);
while (de = readdir(dp)) {
printf(%s\n,de-d_name);
}
closedir(dp);
return 0;
}
fails. I'll upgrade and see if that improves matters.
--sigbjorn
- Original Message -
From: Brian Smith [EMAIL PROTECTED]
To: glasgow-haskell-bugs@haskell.org
Sent: Monday, August 08, 2005 10:31
Subject: Re: getDirectoryContents fails in GHC 6.5 snapshots,works in GHC
6.4.1 snapshots
On 8/8/05, Simon Marlow [EMAIL PROTECTED] wrote:
On 29 July 2005 23:53, Brian Smith wrote:
On 7/20/05, Brian Smith [EMAIL PROTECTED] wrote:
This bug breaks Cabal 1.0 and Cabal 1.1.1.
Expected results: passed
Actual results: *** Exception: c:\: getDirectoryContents: failed (No
error)
I tried various versions and couldn't reproduce the error. I tried:
Yes, it fails for every directory. I actually noticed the problem by
when using Cabal, which uses getDirectoryContents. But, I did some
more testing. This works:
ghc --make Main.lhs -o main
main
passed
But, this fails:
ghci Main.lhs
Prelude Main main
*** Exception: C:\temp\bugs\getDirectoryContents:
getDirectoryContents: failed (
No error)
and this fails:
runghc Main.lhs
*** Exception: C:\temp\bugs\getDirectoryContents:
getDirectoryContents: failed (
No error)
This indicates to me that there is not any problem with my filesystem.
Instead, it seems like it is likely a problem with the linker. Now, I
see what the cause of the problem is:
http://www.haskell.org//pipermail/cvs-ghc/2005-June/025579.html
Sigbjorn Finne sof at galois.com wrote on Mon Jun 20 12:29:24 EDT 2005:
I'll switch over to using gcc-3.4.2 for the nightly builds to see where
takes us.
And, in my previous message I wrote:
Build 20050620 works fine, but Build 20050622 fails.
I noticed that on 2005-06-21 the build failed. I also noticed that
before 2005-06-21, the tar.gz's are ~1 larger than the ones after
2005-06-21.
- Brian
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Feature request: Windows ZIP Distribution
Bulat Ziganshin [EMAIL PROTECTED] writes: SF That's an impressive reduction in size; compressing the SF CAB file inside the MSI using the LZW-based compressor SF that Microsoft provides with their 'makecab' utility didn't LZX (very different from LZW, born long ago, in 1984) btw, while writing this letter i compressed GHC 6.4 installation with cabarc. it results in 33 megs only (!). may be when you creating your installation, you are using MSZIP compression instead of LZX? or you compress with LZX:15, i.e. with minimal 32 kb dictionary instead of LZX:21? Cool, thanks for trying this out, Bulat. When fixing on MSZIP as the compressor for the tool that creates these MSIs sometime ago, I did play with different memory sizes for LZX, but the resulting installers didn't reduce space usage by all that much, so I opted to just go with the cheapcheerful MSZIP. This wasn't with GHC installers though, and as your experience shows that fixing on always using MSZIP wasn't such a good idea. I'll go with LZX for the next GHC release, as I'm able to reproduce what you're seeing. ... Re: lzma, 7-zip: I'm not questioning the improvements possible going this route, just that I won't be doing it for now. Others are free to offer up other distribution forms, of course. However, as an end-user on a Windows platform, I do prefer using non-executable installers. --sigbjorn ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Feature request: Windows ZIP Distribution
That's an impressive reduction in size; compressing the CAB file inside the MSI using the LZW-based compressor that Microsoft provides with their 'makecab' utility didn't make much of a difference in size (but increased compression time quite a bit.) I'm idly speculating that LZMA's larger dictionaries is what's paying off here. Thanks for the pointer, I'll definitely play with it. I'm not planning on switching to 7-Zip in the near future though. However, I think Brian Smith's suggestion of offering up a .zip'ed up version of the GHC distribution tree is a good one plan to do that for the next release. It can then be used to derive other distribution/installer formats. --sigbjorn - Original Message - From: Bulat Ziganshin [EMAIL PROTECTED] To: Sigbjorn Finne [EMAIL PROTECTED] Cc: glasgow-haskell-bugs@haskell.org Sent: Wednesday, May 18, 2005 23:09 Subject: Re[2]: Feature request: Windows ZIP Distribution Hello Sigbjorn, Wednesday, May 18, 2005, 8:38:55 PM, you wrote: SF The 6.4 installer has a UI bug that may prevent you from using SF it on a box where you don't have admin privs. Try starting up the installer, SF hit Next, followed by Back. That should bring up a dialog letting you choose SF whether to perform a user or machine wide installation. Select the former nice bug! :) you can cut installer size in 1.5-2 times by repacking it with another compressor - LZMA. i tried this on the your 6.4 distribution and whole installed directory was packed down to 26 megs to get this work you can either switch to Nullsoft installer, which has support for LZMA, or create self-extracting module with help of 7-zip (www.7-zip.org) anf include this self-extractor in your installer in order to test lzma compression, download abovementioned 7-zip and try it on some directory with the following cmdline: 7z a archive -r -mx9 -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Feature request: Windows ZIP Distribution
One e-mail regarding this would do.. :) The 6.4 installer has a UI bug that may prevent you from using it on a box where you don't have admin privs. Try starting up the installer, hit Next, followed by Back. That should bring up a dialog letting you choose whether to perform a user or machine wide installation. Select the former and proceed as before. Hopefully that does it. Distributing a .zip wouldn't be a big deal, just want to make sure it is solving a real problem. --sigbjorn - Original Message - From: Brian Smith To: glasgow-haskell-bugs@haskell.org Sent: Wednesday, May 18, 2005 08:57 Subject: Feature request: Windows ZIP Distribution Hi, I think it would be convenient for some users (including me at this particular moment) if the Windows binary distribution of GHC was available as a ZIP file. My laptop died and I am using a shared computer with the Windows Installer disabled, thus I cannot use the MSI distribution. Maybe other people have similar situations. Note that ZIP files (unlike TAR.GZ files) can be unzipped in Windows XP without any third-party tools. Thanks, Brian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Build problem from CVS ...?
Did you do a 'cvs up' with the -d option to have it create new directories? ghc/lib/compat/include contains directory.h, and is a fairly new addition. --sigbjorn - Original Message - From: David Duke [EMAIL PROTECTED] To: glasgow-haskell-bugs@haskell.org Sent: Tuesday, April 26, 2005 06:59 Subject: Build problem from CVS ...? I've been running ghc6.5, downloaded and built along with the other tools in the fptools cvs repository (I have no pressing need for cutting edge code, but using the fptools repository is convenient in providing everything in the one place!). This morning I updated my repository and tried to rebuild; that failed, so I ran update again, made distclean, and tried again (autoreconf, ./configure, make) ... Compilation is failing in ghc with the following error: ===fptools== Recursively making `boot' in compat ... PWD = /home/djd/builds/fptools/ghc/lib ==fptools== make boot - --no-print-directory -r; in /home/djd/builds/fptools/ghc/lib/compat ../../../glafp-utils/mkdependC/mkdependC -f .depend-I. -Iinclude -I../../includes -- -O-- cbits/directory.c cbits/rawSystem.c cbits/directory.c:11:23: directory.h: No such file or directory cbits/directory.c:11:23: directory.h: No such file or directory Indeed, there is no file directory.h under the source tree. Should this have been created during configuration - either way, any suggestions on why it is missing? thanks, David ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [nightly] 26-Apr-2005 build of HEAD on OpenBSD/x86
Ditto w/ HEAD -- the compilation error refers to 'stderr'. For that to work, 'stderr' has to be an lvalue, which is an unsound assumption (mingw defines it as (_iob[STDERR_FILENO]).) --sigbjorn - Original Message - From: Conal Elliott [EMAIL PROTECTED] To: glasgow-haskell-bugs@haskell.org Sent: Tuesday, April 26, 2005 09:46 Subject: FW: [nightly] 26-Apr-2005 build of HEAD on OpenBSD/x86 I am getting this same barfage on WinXP (invalid lvalue in unary `' while compiling raisezh_fast in Exception.cmm). From cvs-ghc mail, it looks like this one has been coming up for a few days now. - Conal -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Donald Bruce Stewart Sent: Tuesday, April 26, 2005 2:25 AM To: [EMAIL PROTECTED] Subject: [nightly] 26-Apr-2005 build of HEAD on OpenBSD/x86 Build description = HEAD on OpenBSD/x86 Build location= /home/dons/head-gcc3 Build config file = /home/dons/head-gcc3/nightly/site/pls/conf-HEAD-manzano Nightly build started on manzano at Tue Apr 26 19:00:17 EST 2005. using existing source tree... ok. (GHC Version 6.5) Updating source tree ... ok. Building stage 1 compiler... failed; relevant barfage is below. Building Haddock ... ok. Building Alex... ok. Building Happy ... ok. No successfully built compilers to test; aborting. The last 30 lines of /home/dons/head-gcc3/logs/i386-unknown-openbsd-stage1 are ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include StoragePriv.h -#include OSThreads.h -#include Apply.h -fvia-C -dcmm-lint -hisuf p_hi -hcsuf p_hc -osuf p_o -prof -c Weak.c -o Weak.p_o ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include StoragePriv.h -#include OSThreads.h -#include Apply.h -fvia-C -dcmm-lint -hisuf p_hi -hcsuf p_hc -osuf p_o -prof -c hooks/FlagDefaults.c -o hooks/FlagDefaults.p_o ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include StoragePriv.h -#include OSThreads.h -#include Apply.h -fvia-C -dcmm-lint -hisuf p_hi -hcsuf p_hc -osuf p_o -prof -c hooks/InitEachPE.c -o hooks/InitEachPE.p_o ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include StoragePriv.h -#include OSThreads.h -#include Apply.h -fvia-C -dcmm-lint -hisuf p_hi -hcsuf p_hc -osuf p_o -prof -c hooks/MallocFail.c -o hooks/MallocFail.p_o
Re: win98, ctrl-c System.system (was: Updated 6.4 Windows installer RC)
Simon Marlow [EMAIL PROTECTED] writes: ... Prelude System.system ls = print *** Exception: C:\WINDOWS\SYSTEM\CMD.EXE: runCommand: does not exist (No such fi le or directory) Prelude System.Cmd.rawSystem ls [] = print _viminfo getname.pl index.html ExitSuccess Prelude System.system false = print *** Exception: C:\WINDOWS\SYSTEM\CMD.EXE: runCommand: does not exist (No such fi le or directory) Prelude System.Cmd.rawSystem false [] = print ExitFailure 1 Works for me! Remember that System.system is executing CMD.EXE, not Cygwin bash, so it'll probably have a different PATH and might not be able to find your Cygwin binaries. Both System.system dir, and System.system c:/cygwin/bin/ls work for me. There's no such thing as cmd.exe on Win9x, it's COMMAND.EXE/COM. Some System.Process.* code ought to be looking at the COMSPEC env variable and not hard-code the name of the command processor. However, I don't think COMMAND.EXE supports the /c switch...why the switch away from just using libc/msvcrt's system() for System.system? --sigbjorn ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: misaligned block returned
Hi, 8 == ERROR_NOT_ENOUGH_MEMORY, which sounds reasonable (albeit cryptic) since Win32 has a default user process size limit of 2Gb. --sigbjorn - Original Message - From: Andreas Marth [EMAIL PROTECTED] To: glasgow-haskell-bugs@haskell.org Sent: Thursday, January 13, 2005 07:41 Subject: misaligned block returned Hi! I tried to pass a big heap to a program and get the following error: getMBlocks: VirtualAlloc failed with: 8 main: internal error: getMBlocks: misaligned block returned Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ That happens even for a Hello world program. The border is 1956M. So +RTS -M1956M -RTS is fine. +RTS -M1957M -RTS yields the error above. PS: I know that is a big heap and I could probably do with less when I track the space leak down, but at the moment it is not worth the effort. I only need a single run that passes. (With probably 2.5 - 3 GB memory usage.) PPS: Please cc any answers to me because I am not subscribed to haskell-glasgow-bugs. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: threadDelay space leak under win32
Fixed now on the STABLE branch, but 6.2.2 and, at least, all previous 6.x releases suffer from this embarrassing mem leak. Thanks for reporting the problem. --sigbjorn - Original Message - From: Simon Marlow [EMAIL PROTECTED] To: Philippa Cowderoy [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, November 08, 2004 07:54 Subject: RE: threadDelay space leak under win32 On 07 November 2004 22:47, Philippa Cowderoy wrote: Using the binary distros of GHC 6.2.1 and 6.2.2 under Win2K, this leaks 12K of memory per second on my machine (as do larger programs using threadDelay in the idle event of a wxHaskell app): module Main where import Control.Concurrent main = (threadDelay 1000) main I've no idea if it also happens on *nix platforms, or with a win32/cygwin build. Yes, that looks like a memory leak somewhere in the Async IO subsystem on Windows. The leak goes away using the threaded RTS on the latest CVS version of GHC, because there we're using plain sleep() calls to implement threadDelay and bypassing AsyncIO. Sigbjorn: you're the owner of the Windows AsyncIO implementation, care to look into this leak? Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Haskell-cafe] hugs segmentation fault
Jon Fairbairn [EMAIL PROTECTED] writes: On 2004-10-29 at 00:50BST Ben Rudiak-Gould wrote: Jon Fairbairn wrote: Well, here's a sample session I recorded just now: C:\\ghc\ghc-6.2.1\bin\ghci Prelude let p = 1 : [2 * x | x - p, x 1] in p [1*** Exception: loop Prelude 123 Fail: thread blocked indefinitely C:\ Does this only happen to me? I'm using Linux, you Windows. I suspect there's a hint there. Has this been reported to Glasgow Haskell bugs? (cc'd) Plenty of times, but maybe not that particular manifestation of the problem. Fixed in 6.2.2 --sigbjorn ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Panic
Hi Arjan, the underlying GNU binutils issue which causes this was fixed some 9 months ago. I've been using a new mingw binutils snapshot for a while which includes it -- it's available from http://www.mingw.org/download.shtml (look for binutils-2.15.90-20040222.) You'll still see the warning from GHCi's linker about relocations, but no need to worry. hth --sigbjorn - Original Message - From: Arjan van IJzendoorn [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 10, 2004 06:49 Subject: Panic Hello GHC people, I'm having a lot of fun with GHC and wxHaskell, but at one point something unwanted happened. I created a version of wxHaskell from source with extra GHC options -prof -auto-all; I wanted to have a profiling version of wxHaskell so I can get a stack trace when my program crashes. The creation and installation of that version of wxHaskell went fine. When I tried to load my project NetEdit into ghci, I got the message at the end of this e-mail. Using ghc (instead of GHCi) gives another message: src/Common.hs:3: Failed to load interface for `Graphics.UI.WX': Could not find interface file for `Graphics.UI.WX' (use -v to see a list of the files searched for) Cheers, Arjan -- C:\dev\netedit\NetEditghci -package wx -lsmilec -ilib\DData:src src\Main.hs ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.2.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Loading package lang ... linking ... done. Loading package concurrent ... linking ... done. Loading package QuickCheck ... linking ... done. Loading package util ... linking ... done. Loading package data ... linking ... done. Loading package wxcore ... linking ... WARNING: Overflown relocation field (# re locs found: 30765) C:/cygwin/usr/local/lib/wxcore0.o: unknown symbol `_CC_LIST' ghc.exe: panic! (the `impossible' happened, GHC version 6.2.1): can't load package `wxcore' Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: heap exhausted error
MessageThanks, tidied up a while back - 6.2.1 includes the fix. --sigbjorn - Original Message - From: herington, dean To: '[EMAIL PROTECTED]' Sent: Monday, May 03, 2004 08:07 Subject: heap exhausted error ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.0.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Prelude :m +List Prelude List [] \\ [1..] interactive: internal error: RTS exhausted max heap size (268435456 bytes) Please report this as a bug to [EMAIL PROTECTED], or http://www.sourceforge.net/projects/ghc/ As the heap exhaustion is expected and user-caused, I'm not sure why the above is an internal error. But I'm reporting it as requested. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Release Candidate for 6.2.1 available
This looks a bit odd; your -v output suggests that GHC is still installed in c:/ghc/ghc-6.2.1/, not in a space-separated directory. What platform is this on? Installing GHC in c:/Program Files/GHC/ seems to work just fine here (w/ XP.) --sigbjorn - Original Message - From: Peter Strand [EMAIL PROTECTED] To: GHC users [EMAIL PROTECTED] Sent: Friday, March 12, 2004 09:33 Subject: Re: Release Candidate for 6.2.1 available Sigbjorn Finne wrote: An installer for Windows users can now also be found in that directory. - Original Message - From: Simon Marlow [EMAIL PROTECTED] Subject: RE: Release Candidate for 6.2.1 available ghc-6.2.20040304 and later are release candidates for 6.2.1 Get them from here: http://www.haskell.org/ghc/dist/stable/dist/ This is your last chance to test... I'm going to freeze the release on Monday (15 March). If installed under a directory with spaces, it fails to produce object files. 6.2 has the same problem, 6.0.1 works. End of output from ghc -v --make t.hs: ... ... C:\ghc\ghc 6.2.1\gcc -BC:\ghc\ghc 6.2.1\gcc-lib/ -I. -I. -c C:\DOCUME~1\peter\ LOCALS~1\Temp\ghc536.s -o t.o Failed: C:\ghc\ghc 6.2.1\gcc -BC:\ghc\ghc 6.2.1\gcc-lib/ -I. -I. -c C:\DOCUME~ 1\peter\LOCALS~1\Temp\ghc536.s -o t.orawSystem: does not exist (No such file or directory) *** Deleting temp files Deleting: C:/DOCUME~1/peter/LOCALS~1/Temp/ghc536.s /Peter ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Hello world fails on Win32
I don't have access to a Win9x system right now, but could you try compiling your example w/ 6.2 as follows: ghc -o main main.hs -pgmac:\\ghc\\ghc-6.2\\gcc.exe -B\C:\GHC\GHC-6.2\gcc-lib/\ (minus any line wrapping my e-mail client will no doubt introduce.) --sigbjorn - Original Message - From: Gour [EMAIL PROTECTED] To: glasgow-haskell-bugs [EMAIL PROTECTED] Sent: Thursday, January 01, 2004 10:49 Subject: Re: Hello world fails on Win32 Simon Peyton-Jones ([EMAIL PROTECTED]) wrote: There's something very mysterious going on. GHC does not depend on you having any particular version of gcc etc; it all comes in the bundle. Yes, it looks mysterious. snp ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: internal error: RTS exhausted max heap size (GHC 6.0.1)
Hi, thanks for the report. The handling of heap overflows on your platform has been cleaned up in the current sources, see: http://haskell.org/pipermail/glasgow-haskell-bugs/2003-October/003699.html http://haskell.org/pipermail/cvs-ghc/2003-October/018987.html --sigbjorn - Original Message - From: Ben Rudiak-Gould [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 14, 2003 00:07 Subject: internal error: RTS exhausted max heap size (GHC 6.0.1) Athlon, Windows 2000, 512MB RAM, GHC 6.0.1 installed from www.haskell.org/ghc/dist/6.0.1/ghc-6-0-1.msi. copy con bug.hs import Data.Array.IO (IOUArray) import Data.Array.MArray (newArray) import Data.Word (Word8) emptyArray :: IO (IOUArray Int Word8) emptyArray = newArray (1,1600) 0 main = undefined ^Z ghci bug.hs ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.0.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Compiling Main ( bug.hs, interpreted ) Ok, modules loaded: Main. *Main foo - newArray (1,1600) 0 :: IO (IOUArray Int Word8) *Main bar - emptyArray interactive: internal error: RTS exhausted max heap size (268435456 bytes) Please report this as a bug to [EMAIL PROTECTED], or http://www.sourceforge.net/projects/ghc/ The foo - line also runs far more slowly than I'd expect it to. -- Ben ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Overflown relocs in ghci
Just to bring this one up-to-date -- Nathan Sidwell contributed a BFD patch a couple of weeks ago which looks as if it fixes the bug referred to below. So, once that fix percolates through to a mingw release, this manual splitting up of object files should be a thing of the past for GHC package builders on win32. --sigbjorn - Original Message - From: Sigbjorn Finne [EMAIL PROTECTED] To: Pasch, Thomas (ACTGRO) [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, October 24, 2003 15:17 Subject: Re: Overflown relocs in ghci Hi, it looks as if you're running into a GNU ld/BFD bug where it emits bogus PE object files that have more than 0x relocations. The last time I looked this bug still wasn't fixed in the BFD codebase there wasn't any noticeable interest in fixing it when I reported the bug a year or two ago. The workaround is to split up the .o files that make up your package into two or more .o's, along the lines of how the base package does it. hth --sigbjorn Pasch, Thomas (ACTGRO) wrote: Hello, I'm working at the haskell-java bridge win32 port (http://sourceforge.net/projects/jvm-bridge). I'm using a recent MinGW installation and a ghc 6.0.1. I can build tests in the Examples directory without a problem. But when using ghci, I got the following: $ ghci -package javavm ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.0.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Loading package lang ... linking ... done. Loading package concurrent ... linking ... done. Loading package haskell98 ... linking ... done. Loading package javavm ... linking ... Overflown relocs: 4 done. Prelude :q Leaving GHCi. What does Overflown relocs mean? It seems to be a problem, because when I try to load HelloWorld.hs: Prelude :load HelloWorld.hs Skipping Class_java_io_PrintStream ( Class_java_io_PrintStream.hs, ./Class_java _io_PrintStream.o ) Skipping Class_java_lang_System ( Class_java_lang_System.hs, ./Class_java_lang_ System.o ) Skipping HelloWorld_JVM ( HelloWorld_JVM.hs, ./HelloWorld_JVM.o ) Skipping Main ( HelloWorld.hs, ./HelloWorld.o ) Ok, modules loaded: Main, HelloWorld_JVM, Class_java_lang_System, Class_java_io_ PrintStream. Prelude Main main ./HelloWorld.o: unknown symbol `___stginit_HelloWorldzuJVM_' Sincerly, Thomas ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Overflown relocs in ghci
Hi, it looks as if you're running into a GNU ld/BFD bug where it emits bogus PE object files that have more than 0x relocations. The last time I looked this bug still wasn't fixed in the BFD codebase there wasn't any noticeable interest in fixing it when I reported the bug a year or two ago. The workaround is to split up the .o files that make up your package into two or more .o's, along the lines of how the base package does it. hth --sigbjorn Pasch, Thomas (ACTGRO) wrote: Hello, I'm working at the haskell-java bridge win32 port (http://sourceforge.net/projects/jvm-bridge). I'm using a recent MinGW installation and a ghc 6.0.1. I can build tests in the Examples directory without a problem. But when using ghci, I got the following: $ ghci -package javavm ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.0.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Loading package lang ... linking ... done. Loading package concurrent ... linking ... done. Loading package haskell98 ... linking ... done. Loading package javavm ... linking ... Overflown relocs: 4 done. Prelude :q Leaving GHCi. What does Overflown relocs mean? It seems to be a problem, because when I try to load HelloWorld.hs: Prelude :load HelloWorld.hs Skipping Class_java_io_PrintStream ( Class_java_io_PrintStream.hs, ./Class_java _io_PrintStream.o ) Skipping Class_java_lang_System ( Class_java_lang_System.hs, ./Class_java_lang_ System.o ) Skipping HelloWorld_JVM ( HelloWorld_JVM.hs, ./HelloWorld_JVM.o ) Skipping Main ( HelloWorld.hs, ./HelloWorld.o ) Ok, modules loaded: Main, HelloWorld_JVM, Class_java_lang_System, Class_java_io_ PrintStream. Prelude Main main ./HelloWorld.o: unknown symbol `___stginit_HelloWorldzuJVM_' Sincerly, Thomas ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: valgrind error
Thanks for the report. That unnecessary copying operation was removed in HEAD a couple of months back; the upcoming 6.2 release includes the changes. --sigbjorn - Original Message - From: Abraham Egnor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, October 11, 2003 08:07 Subject: valgrind error Just for fun, I decided to run valgrind on the empty program, i.e. main = return (), compiled with ghc 6.0.1. Much to my surprise, it found an error: ==21117== Source and destination overlap in strcpy(0xbc02, 0xbc04) ==21117==at 0x40021E99: strcpy (mac_replace_strmem.c:87) ==21117==by 0x8063D45: setupRtsFlags (in /home/abe/src/haskell/test/empty) ==21117==by 0x402B3DBD: __libc_start_main (in /lib/libc-2.3.2.so) ==21117==by 0x8049320: (within /home/abe/src/haskell/test/empty) I'm not sure whether this is even a bug or just an artifact of weird memory handing in the RTS, but it's worrying either way. Abe ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: GHCi bug - the impossible happened loading FranTk with ghc-6.0 on Win32
I tidied up this aspect of TclHaskell / FranTk as part of a Galois project a while ago. Attached are the as-is changes needed to avoid being dependent on RTS internals stop doing a busy wait. In addition to these diffs, you also want to comment out the defn of isOnlyProcess in TclCompatibilityGhcSupportsConcurrency.hs hth --sigbjorn - Original Message - From: Simon Peyton-Jones [EMAIL PROTECTED] To: GHC bugs [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Meurig Sage [EMAIL PROTECTED] Sent: Monday, June 23, 2003 02:32 Subject: RE: GHCi bug - the impossible happened loading FranTk with ghc-6.0 on Win32 Simon The underlying problem is that no one is maintaining FranTk at the moment. Perhaps you'd like to? Anyway, FranTk seems to use an un-documented (and therefore unreliable) hook into GHC's RTS. When you use GHCi to load systems that link to RTS hooks, the dynamic linker's symbol table must be initialised to include those symbols. So the 'solution' here is to add 'run_queue_hd' to the RTS_SYMBOLS in ghc/rts/Linker.c. You'll need to build GHC from source do to this. Longer term, it'd be a good plan to see just what FranTk wants to know here, and what API the RTS should expose to support it. Admittedly, ghci dies with a rather unhelpful message Simon | -Original Message- | From: Meurig Sage [mailto:[EMAIL PROTECTED] | Sent: 12 June 2003 16:26 | To: Simon Peyton-Jones | Cc: Meurig Sage | Subject: Re: GHCi bug - the impossible happened loading FranTk with ghc-6.0 on Win32 | | Hi Simon | ... | | That being said as far as I remember: | FranTk contains the following function which attempts to check whether there | are any other threads waiting to be scheduled. If there are none then it | blocks waiting for more user input events, if there are any then it simply | queries the user input event queue and returns immediately. This makes use | of a variable run_queue_hd exported by Schedule.h (I think) in the ghc | run-time system. When I was working on this in ghc-5.0x ghc compiled ghc | code provided access to this variable but ghc-i did not. Not sure what Simon | Marlow has done to this since. | | Hope this helps | | The function that does the check is the following one in | FranTk/TclHaskellSrc/TclCompatibilityGhcSupportsConcurrency.hs. | | | isOnlyProcess :: IO Bool | isOnlyProcess = fmap toBool $ _casm_ ``%r = run_queue_hd == END_TSO_QUEUE;'' | where | toBool :: Int - Bool | toBool 0 = False | toBool _ = True | | Meurig | | - Original Message - | From: Simon Peyton-Jones [EMAIL PROTECTED] | To: Meurig Sage [EMAIL PROTECTED] | Sent: Thursday, June 12, 2003 2:13 PM | Subject: FW: GHCi bug - the impossible happened loading FranTk with ghc-6.0 | on Win32 | | | Hi Meurig | | Are you still around? Do you remember what the issue is here? We | havn't the foggiest idea | | Simon | | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Guest, | Simon | Sent: 12 June 2003 09:12 | To: [EMAIL PROTECTED] | Subject: GHCi bug - the impossible happened loading FranTk with ghc-6.0 | on Win32 | | I can use FranTk with GHC-6.0 on Windows XP just fine in some | configurations. | It's OK when compiling with GHC. It's also OK with GHCi when using | FranTk with no concurrency. | | However, when trying to load a concurrency enabled FranTk into GHCi, I | get the impossible happened. | | I tried the workaround for the other GHCi bug, but this apparently | different, as shown below. | | Full disclosure requires me to highlight the following text from the | FranTk makefile: | | # Ununcomment this line to support concurrency. | # This support does NOT work with ghci. It does not currently export | # the special run_head_queue variable. Will allegedly | # be fixed in a future version of ghc. | | # this version supports concurrency | SUPPORTCONCURRENCY = TclCompatibilityGhcSupportsConcurrency.hs | | Is it simply that this hasn't been fixed yet? (I'm not sure what | symptoms are expected.) | I'd very much like to be able to use FranTk with concurrency. Any | chance of a fix? | | cheers, | Simon | | | sjg-pc$ ghci |___ ___ _ | / _ \ /\ /\/ __(_) | / /_\// /_/ / / | | GHC Interactive, version 6.0, for Haskell 98. | / /_\\/ __ / /___| | http://www.haskell.org/ghc/ | \/\/ /_/\/|_| Type :? for help. | | Loading package base ... linking ... done. | Loading package lang ... linking ... done. | Loading package text ... linking ... done. | Prelude :t GHC.Err.error | GHC.Err.error :: forall a. [Char] - a | Prelude :set -package FranTk | Loading package concurrent ... linking ... done. | Loading package haskell98 ... linking ... done. | Loading package util ... linking ... done. | Loading package data ... linking ... done. | Loading package FranTk ... linking ... |
Re: GHCi bug - the impossible happened loading FranTk with ghc-6.0 on Win32
Sigh, this time with an attachement.. - Original Message - From: Sigbjorn Finne [EMAIL PROTECTED] To: Simon Peyton-Jones [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, June 23, 2003 12:53 Subject: Re: GHCi bug - the impossible happened loading FranTk with ghc-6.0 on Win32 I tidied up this aspect of TclHaskell / FranTk as part of a Galois project a while ago. Attached are the as-is changes needed to avoid being dependent on RTS internals stop doing a busy wait. In addition to these diffs, you also want to comment out the defn of isOnlyProcess in TclCompatibilityGhcSupportsConcurrency.hs hth --sigbjorn - Original Message - From: Simon Peyton-Jones [EMAIL PROTECTED] To: GHC bugs [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Meurig Sage [EMAIL PROTECTED] Sent: Monday, June 23, 2003 02:32 Subject: RE: GHCi bug - the impossible happened loading FranTk with ghc-6.0 on Win32 Simon The underlying problem is that no one is maintaining FranTk at the moment. Perhaps you'd like to? Anyway, FranTk seems to use an un-documented (and therefore unreliable) hook into GHC's RTS. When you use GHCi to load systems that link to RTS hooks, the dynamic linker's symbol table must be initialised to include those symbols. So the 'solution' here is to add 'run_queue_hd' to the RTS_SYMBOLS in ghc/rts/Linker.c. You'll need to build GHC from source do to this. Longer term, it'd be a good plan to see just what FranTk wants to know here, and what API the RTS should expose to support it. Admittedly, ghci dies with a rather unhelpful message Simon | -Original Message- | From: Meurig Sage [mailto:[EMAIL PROTECTED] | Sent: 12 June 2003 16:26 | To: Simon Peyton-Jones | Cc: Meurig Sage | Subject: Re: GHCi bug - the impossible happened loading FranTk with ghc-6.0 on Win32 | | Hi Simon | ... | | That being said as far as I remember: | FranTk contains the following function which attempts to check whether there | are any other threads waiting to be scheduled. If there are none then it | blocks waiting for more user input events, if there are any then it simply | queries the user input event queue and returns immediately. This makes use | of a variable run_queue_hd exported by Schedule.h (I think) in the ghc | run-time system. When I was working on this in ghc-5.0x ghc compiled ghc | code provided access to this variable but ghc-i did not. Not sure what Simon | Marlow has done to this since. | | Hope this helps | | The function that does the check is the following one in | FranTk/TclHaskellSrc/TclCompatibilityGhcSupportsConcurrency.hs. | | | isOnlyProcess :: IO Bool | isOnlyProcess = fmap toBool $ _casm_ ``%r = run_queue_hd == END_TSO_QUEUE;'' | where | toBool :: Int - Bool | toBool 0 = False | toBool _ = True | | Meurig | | - Original Message - | From: Simon Peyton-Jones [EMAIL PROTECTED] | To: Meurig Sage [EMAIL PROTECTED] | Sent: Thursday, June 12, 2003 2:13 PM | Subject: FW: GHCi bug - the impossible happened loading FranTk with ghc-6.0 | on Win32 | | | Hi Meurig | | Are you still around? Do you remember what the issue is here? We | havn't the foggiest idea | | Simon | | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Guest, | Simon | Sent: 12 June 2003 09:12 | To: [EMAIL PROTECTED] | Subject: GHCi bug - the impossible happened loading FranTk with ghc-6.0 | on Win32 | | I can use FranTk with GHC-6.0 on Windows XP just fine in some | configurations. | It's OK when compiling with GHC. It's also OK with GHCi when using | FranTk with no concurrency. | | However, when trying to load a concurrency enabled FranTk into GHCi, I | get the impossible happened. | | I tried the workaround for the other GHCi bug, but this apparently | different, as shown below. | | Full disclosure requires me to highlight the following text from the | FranTk makefile: | | # Ununcomment this line to support concurrency. | # This support does NOT work with ghci. It does not currently export | # the special run_head_queue variable. Will allegedly | # be fixed in a future version of ghc. | | # this version supports concurrency | SUPPORTCONCURRENCY = TclCompatibilityGhcSupportsConcurrency.hs | | Is it simply that this hasn't been fixed yet? (I'm not sure what | symptoms are expected.) | I'd very much like to be able to use FranTk with concurrency. Any | chance of a fix? | | cheers, | Simon | | | sjg-pc$ ghci |___ ___ _ | / _ \ /\ /\/ __(_) | / /_\// /_/ / / | | GHC Interactive, version 6.0, for Haskell 98. | / /_\\/ __ / /___| | http://www.haskell.org/ghc/ | \/\/ /_/\/|_| Type :? for help. | | Loading package base
Re: COM events with HaskellDirect?
Yes, examples/ie-listen/ in the HDirect distrib demonstrates how to sink events (from IE, in that particular example.) --sigbjorn [btw, the CVS version of HDirect was updated a while ago to work with current versions of GHC Hugs.] - Original Message - From: Paul Steckler [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, March 21, 2003 14:07 Subject: COM events with HaskellDirect? A user asks: Is it possible to have a COM component scripted with Haskell invoke Haskell code via a COM event? -- Paul ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: getProtocolNumber garbage (was: Network on Win98: failed - socket - no error ??)
Thanks for chasing this one down. WinSock only supports 'short's as protocol numbers in 'protoent's, whereas 'int's seems to be the norm, hence the garbled result. Shouldn't be too hard to fix. --sigbjorn - Original Message - From: Claus Reinke [EMAIL PROTECTED] To: Simon Peyton-Jones [EMAIL PROTECTED]; Sigbjorn Finne [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, March 07, 2003 11:06 Subject: getProtocolNumber garbage (was: Network on Win98: failed - socket - no error ??) okay, after giving myself a day to recover from the frustration, I've given it fresh try today, and can at last report the source of the problem and a workaround (thanks to Sigbjorn for helping me to narrow down the source). I leave precise location of the bug and proper fix to the experts:-) ghc's 'getProtocolNumber tcp' returns garbage on my win98 box (ghc-5.04.2, perhaps a marshalling problem??). perl's version gives me: 6 ghc's version gives me: 1398538246 Putting in the more sensible value explicitly makes the program work as expected, so winsock was really quite right to report WSAEAFNOSUPPORT 10047 Address family not supported by protocol family, just that I didn't expect the error to be with the parameters.. (and my hacked-up error-reporting didn't include the erroneous values themselves..). On the topic of libraries: although ghc doesn't value binary compatibility as high as its user's do;-) I would expect the libraries to develop faster than ghc's binary incompatibilities in the near future (or is this unreasonable?). So it would really be useful to have regular binary snapshots of the libaries, built to work with(*) the latest binary release of GHC, but distributed separately. When the current libraries can no longer be built for the latest GHC release, it's a sure sign that a new one is needed.. (*) note that this might well be different from built with, as long as the ghc modifications needed do not compromise binary compatibility. A word of caution here. Parts of the libraries, especially base/GHC/*, may be GHC-version-specific. We do not put lots of ifdefs in the library sources to cope with different GHC versions, because they are expected to be built with the GHC from the same tree. So, it may work, but it may not. The usual cvs-rule is not to check in things that don't compile, so even without lots of ifdefs, it would be useful to have a simple text file for each package, stating the version of GHC/Hugc/nhc with which it was compiled (and wether or not it compiles with the latest binary release?). Btw, does the web interface to the cvs-tree give me an easy way to see the precise source versions wich make up the latest binary release? I find it difficult to check whether there have been any changes relevant to my problems. A good start would be to have the tag for the latest binary release as the selected diff target by default? Finally cheerful again, Claus ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Network on Win98: failed - socket - no error ??
Something's up with your WinSock setup on that machine, I suspect -- works fine on the Win98 box I tested it on. You may want to investigate whether the 'identical' client written in C (or some such) behaves as expected on that box.. The HEAD version of the 'network' package tidies up the propagation of WinSock errors. It also drops the need for the user to remember to use withSocketsDo. --sigbjorn - Original Message - From: Claus Reinke [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 05, 2003 04:36 Subject: Re: Network on Win98: failed - socket - no error ?? [moved from ghc-users] I'm still not sure what I'm doing wrong in using the Network library, (inserting WSAGetLastError after the socket call returns 10047 - address family not supported by protocol family; better than no error, but what do I do about it? modified source attached for reference), but the handling of errors in Network now definitely looks like a bug to me: When the implementation is based on WinSock, functions should not check for errno, but for WSAGetLastError, especially so if control-flow depends on the result.. Cheers, Claus WSAEAFNOSUPPORT 10047 Address family not supported by protocol family. An address incompatible with the requested protocol was used. All sockets are created with an associated address family (that is, AF_INET for Internet Protocols) and a generic protocol type (that is, SOCK_STREAM). This error is returned if an incorrect protocol is explicitly requested in the socket call, or if an address of the wrong family is used for a socket, for example, in sendto. Still looking for inspirations on this one. I'm not at all sure I interpret the chain of indirections in the CVS sources correctly, but Network.Socket uses throwErrnoIfMinus1Retry, which does indeed try to use errno to figure out what went wrong. Is that redirected anywhere for windows? Because, in their infinite wisdom, the designers of Windows Sockets have decided that errno isn't the way: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/win sock/error_codes_errno_h _errno_and_wsagetlasterror_2.asp Platform SDK: Windows Sockets 2 Error Codes - errno, h_errno and WSAGetLastError Error codes set by Windows Sockets are not made available through the errno variable. Additionally, for the getXbyY class of functions, error codes are not made available through the h_errno variable. Instead, error codes are accessed by using the WSAGetLastError function. This function is provided in Windows Sockets as a precursor (and eventually an alias) for the Microsoft® Windows® function GetLastError. This is intended to provide a reliable way for a thread in a multithreaded process to obtain per-thread error information. ... Just trying to make sure that I'm worrying about the right error message.. Cheers, Claus - Original Message - From: Claus Reinke [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, March 03, 2003 12:14 PM Subject: Network on Win98: failed - socket - no error ?? I'm playing with the Network library (the recommended portable way?) and have a surprising problem with a simple client/server example. As the same program works fine on Solaris and Win2k, I suspect its a standard feature and someone here with more network programming experience might be able to enlighten me? - Server: listenOn port, then accept handle and enter loop, echoing from handle to stdout - Client: connectTo localhost port, then enter loop echoing from stdin to handle Both programs work on Solaris and Win2k, but fail on Win98, with: Fail: failed Action: socket Reason: No error which would be merely amusing, I guess, if I knew what it meant, and what to do about it? Cheers, Claus ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: GHC Undefined
If you're mixing code compiled and linked with different versions of binutils / gcc, then you're pretty much on your own - i.e., I'm assuming you didn't build pdcurses via 'ghc' but 'gcc' 'ld'/'dllwrap'. --sigbjorn - Original Message - From: michael vorin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 11, 2002 14:13 Subject: GHC Undefined Whilst I was trying to get the curses binding example in QForeign to compile - I stumbled on what I believe to be a bug. Essentialy I believe that the version of ld.exe that you have packaged up with ghc 5.04 win32 has a bug or is perhaps badly configured. ghc uses - GNU ld version 2.11.90 (20010704) (with BFD 2.11.90) which did not properly resolve external references to variables (see below). I resolved problem by using - GNU ld version 2.13, from current mingw release. my configuration GHC 5.04 Win32 running on win2K platform. What I encountered ghc -fglasgow-exts CursesTest.hs CursesTest_hsc.c Curses.hs curses_hsc.c -lpdcurses curses_hsc.o(.text+0x4):curses_hsc.c: undefined reference to `stdscr' curses_hsc.o(.text+0x10):curses_hsc.c: undefined reference to `LINES' curses_hsc.o(.text+0x1c):curses_hsc.c: undefined reference to `COLS' curses_hsc.o(.text+0x28):curses_hsc.c: undefined reference to `COLOR_PAIRS' curses_hsc.o(.text+0x34):curses_hsc.c: undefined reference to `COLORS' when I had a look at the object files and the libpdcurses.dll, the appropriate symbols were in fact defined, and in fact all functions were resolved, the above symbols represent bindings to variables declared as follows:- extern int LINES; 2. setup of a test - I setup a test (test.c attached) where I just had one external reference that I was trying to resolve. I compiled it curses\tst-linesghc tst.c -o tst.exe -lpdcurses tst.o(.text+0x4):tst.c: undefined reference to `LINES' curses\tst-linesgcc tst.c -o tst.exe -lpdcurses Info: resolving _LINES by linking to __imp__LINES (auto-import) the above should give the same result, i.e. the later result 3. fix I copied ld.exe from my mingw release (version 2.13) over ld.exe in the ghc release (version 2.11.90 ). This solved my problem 4. postmortem - why the problem ? Does this problem occur with all external variable references or is limitted to a few dll libraries, does it occur linking against static libraries ? I don't know _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: import ambiguity
Hi, thanks for the report. Now fixed. --sigbjorn - Original Message - From: Dean Herington [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, October 23, 2002 09:14 Subject: import ambiguity With the program: import Exception main = let catch = Prelude.catch in catch (print ok) print hugs 98 version 20021021 gives: ... Dependency analysis ERROR ImportAmbiguity.hs:2 - Ambiguous variable occurrence catch *** Could refer to: Prelude.catch Exception.catch ... ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Directory.doesDirectoryExist inconsistency
That would take care of the incompatibility here, but it's a slippery slope. Should Haskell provide you with a platform-independent view of filenames and file systems? --sigbjorn - Original Message - From: Simon Peyton-Jones [EMAIL PROTECTED] To: Sigbjorn Finne [EMAIL PROTECTED]; Claus Reinke [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, October 22, 2002 08:50 Subject: RE: Directory.doesDirectoryExist inconsistency Sigbjorn (and others interested in Win32 I/O behaviour) The fact that MS CRT differs from Unix doesn't mean that the Haskell interface should necessarily differ. The Haskell impl of doesDirectoryExist could, on Win32, trim off trailing '/' or '\', in order to make the behaviour consistent. Where it's possible to get consistent behaviour, we should strive for that. Do you agree? Simon | -Original Message- | From: Sigbjorn Finne [mailto:sof;galois.com] | Sent: 16 October 2002 15:54 | To: Claus Reinke | Cc: [EMAIL PROTECTED] | Subject: Re: Directory.doesDirectoryExist inconsistency | | This is known behaviour of the MS CRT implementation | of stat() on directories -- trailing slashes will cause it to | report ENOENT. | | Undesirable behaviour, you might (reasonably) say, but | the format of FilePaths is left system-specific by Haskell98. | | --sigbjorn | | - Original Message - | From: Claus Reinke [EMAIL PROTECTED] | To: [EMAIL PROTECTED] | Sent: Wednesday, October 16, 2002 07:21 | Subject: Directory.doesDirectoryExist inconsistency | | | I've just been chasing a portability problem, where a largish third-party | program works fine on our suns (ghc-5.02.3), but chokes under | cygwin/windows (ghc-5.04). Comes down to an inconsistency in the | handling of (trailing?) slashes in Directory.doesDirectoryExist (see | a and b below). | | ... | | ___ | Glasgow-haskell-bugs mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Newbie building GHC
Here's more background info:
- On a Redhat 7.2 box, install the ghc-5.04.1 RPM
- do the following:
rh7.2$ cat M.hs
module M where { import System; main = system uname = print }
rh7.2$ ghc -o m M.hs
rh7.2$ ./m
ExitFailure 127
You can also reproduce this using just C code by compiling
up the attached invoke.c file on a RedHat 7.3 box, and
then linking it together with this little test stub on a RH7.2
box:
rh7.3$ gcc --version
2.96
rh7.3$ gcc -O -c invoke.c
---
rh7.2$ gcc --version
2.96
rh7.2$ gcc -o main main.c invoke.o
rh7.2$ ./main
127
rh7.2$
Peering at the generated binaries and assembly output, it
appears as if BFD (= assembler/linker) has changed
the code it emits to refer to strings in the read-only
data section.
Fascinating though that is, avoiding mixing code built on
these two 'platforms' is probably the only valuable piece
of info to take away from all this.
May I suggest the GHC downloads page drops the claim
that the 5.04.1 RPMs will work under RH7.2?
--sigbjorn
- Original Message -
From: Sigbjorn Finne [EMAIL PROTECTED]
To: Saswat Anand [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, September 26, 2002 08:52
Subject: Re: Newbie building GHC
Hi there,
we've been running into similar problems here on a Redhat 7.2
box using the ghc-5.04.1 RPM (which was built on RedHat 7.3).
The salient line from your strace output is the following one:
[pid 1514] execve(n/sh, [/bin/sh, -c, gcc Adjustor.c
-o /tmp/ghc1513.s...], [/* 36 vars */])
= -1 ENOENT (No such file or directory)
execl() (called by System.system) is somehow causing execve()
to be invoked with a stripped off command arg.
The cause of this suspected outbreak of Linux versionitis is as yet
unknown (gcc? glibc?..), but you may want to try installing the
.tar.bz2 instead (which was built on a RH 7.2 box.) That worked
around the problem here, at least.
hth
--sigbjorn
#include unistd.h
#include sys/wait.h
#include errno.h
#include stdio.h
int
invokeCmd(char* cmd)
{
int pid;
int wstat;
switch(pid = fork()) {
case -1:
if (errno != EINTR) {
return -1;
}
case 0:
{
/* the child */
execl(/bin/sh, sh, -c, cmd, NULL);
_exit(127);
}
}
while (waitpid(pid, wstat, 0) 0) {
if (errno != EINTR) {
return -1;
}
}
if (WIFEXITED(wstat))
return WEXITSTATUS(wstat);
else if (WIFSIGNALED(wstat)) {
errno = EINTR;
}
else {
/* This should never happen */
}
return -1;
}
Re: Newbie building GHC
Oops, while trivial, I forgot to include the main.c test
wrapper:
foo$ cat main.c
#include stdio.h
extern int invokeCmd(char* cmd);
int main() {
printf(%d\n, invokeCmd(uname));
return 0;
}
--sigbjorn
- Original Message -
From: Sigbjorn Finne [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; Saswat Anand [EMAIL PROTECTED]
Sent: Thursday, September 26, 2002 12:18
Subject: Re: Newbie building GHC
Here's more background info:
- On a Redhat 7.2 box, install the ghc-5.04.1 RPM
- do the following:
rh7.2$ cat M.hs
module M where { import System; main = system uname = print }
rh7.2$ ghc -o m M.hs
rh7.2$ ./m
ExitFailure 127
You can also reproduce this using just C code by compiling
up the attached invoke.c file on a RedHat 7.3 box, and
then linking it together with this little test stub on a RH7.2
box:
rh7.3$ gcc --version
2.96
rh7.3$ gcc -O -c invoke.c
---
rh7.2$ gcc --version
2.96
rh7.2$ gcc -o main main.c invoke.o
rh7.2$ ./main
127
rh7.2$
Peering at the generated binaries and assembly output, it
appears as if BFD (= assembler/linker) has changed
the code it emits to refer to strings in the read-only
data section.
Fascinating though that is, avoiding mixing code built on
these two 'platforms' is probably the only valuable piece
of info to take away from all this.
May I suggest the GHC downloads page drops the claim
that the 5.04.1 RPMs will work under RH7.2?
--sigbjorn
- Original Message -
From: Sigbjorn Finne [EMAIL PROTECTED]
To: Saswat Anand [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, September 26, 2002 08:52
Subject: Re: Newbie building GHC
Hi there,
we've been running into similar problems here on a Redhat 7.2
box using the ghc-5.04.1 RPM (which was built on RedHat 7.3).
The salient line from your strace output is the following one:
[pid 1514] execve(n/sh, [/bin/sh, -c, gcc Adjustor.c
-o /tmp/ghc1513.s...], [/* 36 vars */])
= -1 ENOENT (No such file or directory)
execl() (called by System.system) is somehow causing execve()
to be invoked with a stripped off command arg.
The cause of this suspected outbreak of Linux versionitis is as yet
unknown (gcc? glibc?..), but you may want to try installing the
.tar.bz2 instead (which was built on a RH 7.2 box.) That worked
around the problem here, at least.
hth
--sigbjorn
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: External Core typechecker
To enable type checking of Core, compile with -dcore-lint --sigbjorn - Original Message - From: Kirsten Chevalier [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 05, 2002 12:05 Subject: External Core typechecker GHC doesn't seem to do much typechecking on external Core files; it happily compiles .hcr files with type errors that then segfault when you run the program. An example of such a program is attached (the type error is on line 19, where cons is applied to the Integer type and two integer lists). I'm using the latest version of GHC (built from CVS sources yesterday, using GHC 5.04 to bootstrap), on a RedHat Linux box with gcc 2.96. -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: External Core typechecker
Kirsten Chevalier [EMAIL PROTECTED] writes: On Thu, Sep 05, 2002 at 12:20:27PM -0700, Sigbjorn Finne wrote: To enable type checking of Core, compile with -dcore-lint Ah, thanks. You'd think it would do that by default when starting from an external Core file (hint :-)) It actually does, but the type checking code that that front-end (re-)uses does just a limited amount of checking (e.g., function applications aren't checked..), hence the suggestion of using the more thorough -dcore-lint --sigbjorn ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: select() failure
Dean Herington [EMAIL PROTECTED] writes: ... When a thread wants to read from a file descriptor, its logic looks like: threadWaitRead (fdToInt fd) ([char], 1) - locked (fdRead fd 1) where `locked` obtains and holds the aforementioned lock for the duration of its argument action. Reflecting on the above, I now realize that the recent change (/fptools/ghc/rts/Select.c?rev=1.22 in GHC 5.04) to wake up all threads when select() returns an EBADF error, though well-intentioned, is inappropriate. The point of `threadWaitRead` and `threadWaitWrite` is to block the calling thread until it's known that a subsequent call involving the given file descriptor will not block. Allowing all threads to continue--even those whose file descriptor is not yet ready--allows for exactly the deadlock that `threadWaitRead` and `threadWaitWrite` are designed to avoid. The assumption is that FDs are marked as non-blocking, so this won't be a problem. Do you have a good reason not to have your FDs marked as such? I consider it a bug in select() that, when EBADF is reported, the sets of ready file descriptors are not also reported. That would be the wrong thing to do, assuming the FD_SETs are in any way valid when select() returns failure. --sigbjorn ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc installer for Windows
Hi, I'm unable to reproduce the error on any local machines, so could you try doing the following: - start up a command shell - cd into the directory where the 5.04 msi files lives - run the following command: c:\downloads msiexec /i ghc-5-04.msi /l* msi.log that will run the MS installer with logging turned on. If you could either send or point me at a copy of the resulting log file, msi.log, that'd be very helpful in trying to narrow down the cause of this. thanks --sigbjorn - Original Message - From: Sigbjorn Finne [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Stephen Eldridge [EMAIL PROTECTED] Sent: Monday, July 15, 2002 06:33 Subject: Fw: ghc installer for Windows Thanks for the report, forwarded to the bugs list. It should be noted that the installer currently assumes that you're an administrator on the machine you're using. --sigbjorn - Original Message - From: Stephen Eldridge [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 15, 2002 05:25 Subject: ghc installer for Windows The current installer for ghc 5.05.1 seems to be faulty. Rather to my surprise, I could only select a drive other than the boot drive by going into the custom menu. Having selected F: I then had to create the directory I wanted - ghc\ghc-5.04 - before I could proceed (something apparently unnecessary had I accepted the default). Unfortunately, the install then stops with the error message that the network location \C:\WINNT\Profiles\All Users\Start Menu\. could not be accessed. If this message is correct then the installer is looking for a malformed address with the single backslash preceding the drive letter. Stephen Eldridge phone: 0161-200-3352email: [EMAIL PROTECTED] Department of Computation, UMIST, Manchester M60 1QD ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Fw: crash with GHC 5.04
Hi, this appears to be GC-related; forwarded to the bugs list. Thanks for the report. --sigbjorn - Original Message - From: Mark Tehver [EMAIL PROTECTED] To: Sigbjorn Finne [EMAIL PROTECTED] Sent: Saturday, July 13, 2002 07:38 Subject: crash with GHC 5.04 Hi again, I have run into another problem that I believe may be a bug in GHC 5.04. Perhaps I should post this to ghc-bugs mailing list as I am not sure if it is a Windows specific issue or something more general. Anyway, the problem is that the example I have attached to this mail crashes. It is a relatively simple example (I encountered a similar problem in a larger program and tried to simplify the issue as much as possible), the C++ program calls several functions that are exported from Haskell. For some reason, crash occours in loop interation 32. This does not seem to be C compiler problem as it happends with both MS VC and GCC. The program does not crash when I use GHC 5.02.3. Mark crash.zip Description: Zip compressed data
Re: unable to create DLL with GHC 5.04
Hi, looks as if you're mixing mingw and cygwin object files. ghc-5.04 is mingw-based, so make sure you feed in the flag -mno-cygwin to gcc when compiling .c files. --sigbjorn - Original Message - From: Mark Tehver [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 11, 2002 12:42 Subject: unable to create DLL with GHC 5.04 Hi! I seem to have some problem building DLLs under Win32 with GHC 5.04. When I follow the instructions from http://haskell.cs.yale.edu/ghc/docs/latest/html/users_guide/win32-dlls-forei gn.html all looks ok until I do the last step. Then linker reports: /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/../../../../i686-pc-cygwin/bin/ld: warning: cannot find entry symbol _DllMainCRTStartup@12; defaulting to 63601000 C:/ghc/ghc-5.04/libHSrts.a(StgMiscClosures.o)(.text+0xab1):StgMiscClosures.h c: undefined reference to `_imp___iob' C:/ghc/ghc-5.04/libHSrts.a(StgMiscClosures.o)(.text+0xae5):StgMiscClosures.h c: undefined reference to `_imp___iob' C:/ghc/ghc-5.04/libHSrts.a(StgMiscClosures.o)(.text+0xb19):StgMiscClosures.h c: undefined reference to `_imp___iob' C:/ghc/ghc-5.04/libHSrts.a(StgMiscClosures.o)(.text+0xb4d):StgMiscClosures.h c: undefined reference to `_imp___iob' C:/ghc/ghc-5.04/libHSrts.a(StgMiscClosures.o)(.text+0xb81):StgMiscClosures.h c: undefined reference to `_imp___iob' C:/ghc/ghc-5.04/libHSrts.a(StgMiscClosures.o)(.text+0xbb5):StgMiscClosures.h c: more undefined references to `_imp___iob' follow collect2: ld returned 1 exit status dllwrap: gcc exited with status 1 With GHC 5.02.x all seemed to work fine... Best regards, Mark ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: GHC on Cygwin
Koen Claessen [EMAIL PROTECTED] writes: ... However, ghci crashes at start up time! I get the following behavior: [lap/bin] -: ./ghci ... Loading package base ... linking ... /d/Work/Packages/Ghc/Install/lib/ghc-5.03/HSbase_cbits.o: unknown symbol `_sigaddset' ghc-5.03: panic! (the `impossible' happened, GHC version 5.03): can't load package `base' ... What to do? I fixed the source of this one last week, so make sure the compiler you're using to _build_ GHCi has got an up-to-date version of ghc/rts/Linker.c Once you do, you need to rebuild its ghc/rts, followed by a re-link of the ghc executable that's invoked in the above. --sigbjorn ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: External Core front-end in GHC 5.03
I'm able to reproduce this with a stage1 build (built using
ghc-5.02.3), but not a stage2 build. Looks as if
parser/ParserCore.y is tickling a bug in 5.02.3 - try
regenerating parser/ParserCore.hs with Happy, but
stay away from the -c option - e.g.,
foo$ happy -g parser/ParserCore.y
followed by a re-make in ghc/compiler. That solves
the problem for me.
--sigbjorn
- Original Message -
From: Kirsten Chevalier [EMAIL PROTECTED]
To: Sigbjorn Finne [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, May 13, 2002 17:26
Subject: Re: External Core front-end in GHC 5.03
On Wed, May 08, 2002 at 07:18:17AM -0700, Sigbjorn Finne wrote:
Hi,
I'm unable to reproduce this here (with a 2002-05-07 HEAD build.)
Make sure no interface files from earlier GHC builds are in scope;
the -dshow-passes output you give hints that this _might_ be the cause.
I'm still having the same problem -- I tried the newest version of GHC
from
CVS (as of today), as well as the April 11 snapshot (ghc-5.03.20020410). I
don't think that any older interface files are in scope -- at least, there
are
none in the same directory as the program being compiled. Any other ideas?
Thanks,
Kirsten
(my original message is below)
- Original Message -
From: Kirsten Chevalier [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, May 03, 2002 15:39
Subject: External Core front-end in GHC 5.03
Hi,
I just downloaded and built the latest version of GHC from the CVS
repository
yesterday and tried to use it to compile an external Core file, which
caused
the compiler to crash:
$ ghc -fext-core -fno-code hello.hs
$ ghc hello.hcr
Segmentation fault
I know that the external Core feature is still a work in progress, but
is
there something I should be doing differently or is it totally broken?
Here
are the relevant details:
$ uname -a
Linux puma 2.4.7-10smp #1 SMP Thu Sep 6 17:09:31 EDT 2001 i686 unknown
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-98)
and the results of compiling with -v:
$ ghc -v hello.hcr
Glasgow Haskell Compiler, Version 5.03, for Haskell 98, compiled by
GHC
version 5.02.1
Using package config file:
/home/crete/lumberjacks3/krc/ghc/fptools-build/ghc/driver/package.conf.inpla
ce
Packages
package stuff snipped
Hsc static
flags: -static -fignore-interface-pragmas -fomit-interface-pragmas -fdo-lamb
da-eta-expansion -flet-no-escape
*** Checking old interface for hs = Just hello.hcr, hspp = Just
hello.hcr:
*** Renamer:
Segmentation fault
The program I'm trying to compile is just:
main = putStr Hello world!
Thanks,
Kirsten
--
Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in
doubt
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: unsafePtrEq in 5.03?
A spot of CVS archeology revealed that it was removed as a primop as part of a NCG overhaul couple of months ago. Don't know if leaving it out was simply an omission or if there's something deeper going on. Anyway, you can approximate the old defn with the following: module PtrEq where import GHC.Base unsafePtrEq :: a - a - Bool unsafePtrEq a b = (unsafeCoerce# a) `eqAddr#` (unsafeCoerce# b) Clearly, it doesn't chase indirections. hth --sigbjorn - Original Message - From: Conal Elliott To: Ghc-Bugs Sent: Tuesday, April 16, 2002 18:43 Subject: unsafePtrEq in 5.03? Did unsafePtrEq disappear between 5.02 and 5.03? - Conal ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: IO.hReady, hWaitForInput differ on Linux / Windows
Hi, I added Win32 support for these a while ago; the 5.03 snapshot includes it. --sigbjorn - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 27, 2002 23:37 Subject: IO.hReady, hWaitForInput differ on Linux / Windows Hi there, I'm using ghc 5.02.2 on Suse Linux 7.3 and Win2000. While on Linux everything seems to work as documented, on Windows 2000 IO.hReady always returns True, which also means that IO.hWaitForInput always blocks even if no input is available. I would be very grateful for any hints how to avoid this problem. Cheers, dirk __ Die Nummer, die man nie vergisst: Ihre persönliche Wunschrufnummer von WEB.DE! Jetzt einsteigen http://freemail.web.de/?mc=990002 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: handling embedded spaces in output from ghc -M]
Hi, you're making a mountain out of a molehill; couple of workarounds spring to mind: * transform the -i path you feed to GHC -M, i.e., something like ghc -M -i`cygpath -w -s c:\Program Files\GreenCard`/lib/ghc * post-process the generated dependencies file to insert the double quotes and/or escape the spaces yourself. --sigbjorn - Original Message - From: Antony Courtney [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 25, 2002 00:14 Subject: [Fwd: handling embedded spaces in output from ghc -M] Hi, I never heard a reply to this. Is there any hope of getting this fixed? If not, I'll have to ship my own private binary release of greencard under windows, just so that it doesn't install in a directory with an embedded space(!) :-( Thanks, -antony -- Antony Courtney Grad. Student, Dept. of Computer Science, Yale University [EMAIL PROTECTED] http://www.apocalypse.org/pub/u/antony ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ghc-5.02.2 panic (was: (no subject))
Hi, looks like a bona fide bug; thanks for reporting it. In order to be able to fix it, any chance of you sending us that Main.hs? thanks, --sigbjorn - Original Message - From: Loffler [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 25, 2002 12:47 Subject: (no subject) Hi, I typed: ghc Main.hs and then GHC said: GHC.EXE: panic! (the `impossible' happened, GHC version 5.02.2): Maybe.fromJust: Nothing Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. -- Maarten ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 'Pretty' does not export ($+$)
Strange, the following compiles just fine with
5.02.1 on a Win2k box:
module Foo where { import Pretty ; x y = y Pretty.$+$ y }
--sigbjorn
- Original Message -
From: Duncan Coutts [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, February 17, 2002 16:13
Subject: 'Pretty' does not export ($+$)
The pretty printing module 'Pretty' in the text package does not export
the
($+$) operator. The documentation says it does (and it certianly should).
I'm using ghc 5.02.1
Duncan
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc.exe: fatal error: Windows programs can only use 256Mb of heap; sorry!
Pasch, Thomas (ACTGRO) [EMAIL PROTECTED] writes: $ ghc -package javavm -c Class_java_awt_Component.hs -o Class_java_awt_Component.o d:\Programme\ghc\ghc-5.02.2\bin\ghc.exe: fatal error: Windows programs can only use 256Mb of heap; sorry! Hello, is there anything I can change in order to avoid this message? The 5.03 snapshot drops this hard-wired restriction, letting you use a larger heap via the -M option. hth --sigbjorn ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: PAP_Entry: CATCH_FRAME
Simon may have gone home for the weekend, so just
to let you know that he's checked in a fix for this
problem in the current CVS sources.
--sigbjorn
- Original Message -
From: Peter White [EMAIL PROTECTED]
To: Simon Marlow [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Friday, February 15, 2002 09:05
Subject: RE: PAP_Entry: CATCH_FRAME
I have managed to create a small program that reproduces the error the way
I
get to it. The output it produces is:
Handler got: 1
Exception: 1st
Handler got: 2
Error1: fatal error: PAP_entry: CATCH_FRAME
The program was in a file Error1.hs, that is why the fatal error begins
with Error1. The program follows, I hope this is helpful.
module Main where
import Concurrent
import qualified Exception as E
trapHandler :: MVar Int - IO ()
trapHandler inVar =
(do { trapMsg - takeMVar inVar
; putStrLn (Handler got: ++ show trapMsg)
; trapHandler inVar
}
)
`E.catch`
(trapExc inVar)
trapExc :: MVar Int - E.Exception - IO ()
trapExc inVar e =
do { putStrLn (Exception: ++ show e)
; trapHandler inVar
}
main :: IO ()
main =
do { inVar - newEmptyMVar
; tid - forkIO (trapHandler inVar)
; yield
; putMVar inVar 1
; threadDelay 1000
; throwTo tid (E.UserError 1st)
; threadDelay 1000
; putMVar inVar 2
; threadDelay 1000
; throwTo tid (E.UserError 2nd)
; threadDelay 1000
; putStrLn All done
}
-Original Message-
From: Simon Marlow [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 15, 2002 2:55 AM
To: Peter White; [EMAIL PROTECTED]
Subject: RE: PAP_Entry: CATCH_FRAME
What does it mean when you get the fatal error PAP_Entry:
CATCH_FRAME. I
am using ghc version 5.03.20020204. I looked in the ghc
source code and the
comment next to this error message says that it cannot happen.
Well, you must be imagining it then :-)
Seriously, I've seen this error too. Try 'interact (unlines.lines)' in
GHCi
and press ^C to see it (this works in 5.02.2 too). I've been meaning to
look at it, hopefully I'll get around to it today.
Cheers,
Simon
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Compiler 5.02 asked me to report a bug.
Hi,
thanks for a fine bug report. The panic you're running
into is something that could be handled more gracefully
by the compiler.
Workaround is simple, just add -fvia-C to your GHC
command-line.
--sigbjorn
btw, I'd encourage you to make your Postgres Haskell
binding available to other Haskell programmers. Looks
like there's plenty of good stuff in there.
- Original Message -
From: Brett Giles [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, February 09, 2002 12:31
Subject: Compiler 5.02 asked me to report a bug.
Hi, While using green-card to create an interface for postgres database
access, I recieved the following when I executed
ghc -c PG.hs -o PG.o -fglasgow-exts -i/usr/local/gc-2.03/lib/ghc
-package text -package data -package util
ghc-5.02: panic! (the `impossible' happened, GHC version 5.02):
Native code generator can't handle foreign call
{-_ccall-}__casm ``do {PGresult * t;int result;
t = (PGresult *)%0;
do { result = PQnfields( t );
%r = (int)(result);} while(0);} while(0);''
Please report it as a compiler bug to [EMAIL PROTECTED],
or http://sourceforge.net/projects/ghc/.
I am using a newly compiled version of green-card (2.03) on Debian
testing. This is interfacing to postgres version 7.1.3, standard Debian
install.
The ghc is the standard Debian testing install asl well.
I have attached the PG.gc ,hs and .hi files, as well as an optional
include file used for hugs...
Please note, this interface has been working for hugs (albeit with
problems)
Please let me know if there is anything I can do to assist in further
debugging.
Brett Giles
Grad Student in formal methods, University of Calgary,
http://www.cpsc.ucalgary.ca/~gilesb
..
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
win32 test installer
A test Windows Installer for the 5.03 snapshot release is now available via http://galois.com/~sof/ghc-5.03-20020208.msi (25.2M) Unless I hear of any fatal flaws encountered using it or I discover glitches while sleeping, it will go up on haskell.org/ghc/ tomorrow morning (PST). --sigbjorn ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Cygwin path support for ghc under Windows?
You have to give more details than this; GHC does support both '/' and '\' as path separator (but, of course, doesn't understand nonsense like /cygdrive prefixes). That GHC doesn't depend on cygwin is a feature, not a bug (but if you want it to, you can compile it up for that 'platform' instead). --sigbjorn - Original Message - From: Antony Courtney [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 29, 2002 07:02 Subject: Cygwin path support for ghc under Windows? Hi, This is more of a question than a bug report, so my appologies for using what is probably the wrong email list. Henrik Nilsson and I have just invested considerable effort in trying to write portable, complete Makefiles for compiling and installing some of our Haskell libraries with ghc under both Linux and Windows. We have invested a lot of work into factoring out platform- and site-specific definitions from the common build rules and target lists. Of course, Cygwin and its port of GNU make is the only thing that makes this idea even vaguely plausible. When I look at the Win32-specific portion of the Makefile, it appears that the *only* reason that I can't write one simple, portable GNU make Makefile that would work on Linux and Windows is because ghc only understands the Windows-style path name convention (with '\' as the path seperator, and ':' for drive letters). All of the other Cygwin tools understand both the Windows-style and Cygwin/POSIX-style path names. What are your thoughts on this matter? Have you considered adding POSIX-style path name support to ghc on Windows, either by hand or by linking with cygwin? After all, any Windows developer worth supporting will have Cygwin installed anyway. :-) If there is interest but lack of resources, I would be happy to have a go at implementing a minimalist form of such support. -antony -- Antony Courtney Grad. Student, Dept. of Computer Science, Yale University [EMAIL PROTECTED] http://www.apocalypse.org/pub/u/antony ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Simple sockets sample?
I don't believe there's a bug in here, only perhaps in the way the Socket functions are used: main = withSocketsDo $ do d - connectTo host port -- (1) sendTo host port GET / HTTP/1.0\r\n\r\n; -- (2) response - recvFrom host port; -- (3) putStrLn response where host = localhost port = Service http (1) is creating a TCP connection, only never to use the handle returned. (2) does effectively the same, but closes the TCP connection after having transmitted the HTTP request -- the web server presumably sees this, but also sees that the client closes the socket. (3) waits for an incoming connection from the web server, which won't happen, as that's not how HTTP works. Someone suggested the following variation: main :: IO () main = do h - connectTo www.yahoo.com (PortNumber 80) hPutStrLn h GET / HTTP/1.0\r\n\r\n response - hGetContents h putStrLn response Almost, I'd make two changes to have it work on all platforms: main :: IO () main = withSocketsDo $ do h - connectTo www.yahoo.com (PortNumber 80) hPutStrLn h GET / HTTP/1.0\r\n\r\n hFlush h response - hGetContents h putStrLn response withSocketsDo is reqd to start up WinSock must always be used if you want your socket code to work under Win32 (removing the need for explicit user-level initialisation is on my ToDo list, however). Having to explicitly flush out the request doesn't look quite right though, I'll have a closer look. hth --sigbjorn - Original Message - From: Simon Marlow [EMAIL PROTECTED] To: Dominic Cooney [EMAIL PROTECTED]; Jens Petersen [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, January 28, 2002 04:36 Subject: RE: Simple sockets sample? I realize that my use of the API was incredibly naïve and that I should have been using h* methods with the handle returned from connectTo. But it is connectTo that is failing as described. It fails interactively too with ghci, and regardless of using Server http or PortNumber 80. The revised code below unfortunately gives the following error: Main main *** Exception: does not exist Action: getProtocolByName Reason: no such protocol entry There were some problems with Sockets on Windows platforms in versions 5.02 and 5.02.1 of GHC. Version 5.02.2 should be better behaved, although I admit I haven't tested this personally. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghci panic
Antony Courtney [EMAIL PROTECTED] writes: ... Skipping HavenTest( HavenTest.hs, ./HavenTest.o ) PEi386 object has suspiciously large string table; 64k relocs? ghc.exe: panic! (the `impossible' happened, GHC version 5.02.1): loadObj: failed Hi, this is a known issue with GHCi's linker, for which there's no good workaround for you other than to try to split up that module. If the module isn't particularly larger than any of the others, please let us know. --sigbjorn ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghci panic (unknown symbol stg_gc_l1)
Hi,
GHCi doesn't load the RTS package (nor GMP),
as they're both baked into the binary. My guess is that
you've built ghci using 5.02.1; you need to use 5.02.2
(i.e., do two stage build.) The missing symbol was
introduced in 5.02.2's RTS.
hth
--sigbjorn
- Original Message -
From: Pixel [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, January 26, 2002 08:07
Subject: ghci panic (unknown symbol stg_gc_l1)
% ghci
[...]
Loading package std ... linking ... /usr/lib/ghc-5.02.2/HSstd.o: unknown
symbol `stg_gc_l1'
ghc-5.02.2: panic! (the `impossible' happened, GHC version 5.02.2):
can't load package `std'
[...]
(it seems) it should load package rts before std, but (it seems) it
doesn't:
% for i in /usr/lib/ghc-5.02.2/*.o; do nm $i | grep -q T stg_gc_l1
echo $i; done
/usr/lib/ghc-5.02.2/HSrts.o
% ghci -v5
[...]
Using package config file: /usr/lib/ghc-5.02.2/package.conf
[...]
Package
{name = std,
import_dirs = [/usr/lib/ghc-5.02.2/imports/std],
source_dirs = [],
library_dirs = [/usr/lib/ghc-5.02.2],
hs_libraries = [HSstd],
extra_libraries = [HSstd_cbits],
include_dirs = [],
c_includes = [HsStd.h],
package_deps = [rts],
extra_ghc_opts = [],
extra_cc_opts = [],
[...]
Loading package std ... linking ... /usr/lib/ghc-5.02.2/HSstd.o: unknown
symbol `stg_gc_l1'
strace -efile ghci doesn't show anything weird, except maybe:
stat64(./Prelude.hs, 0xbfffcfe0) = -1 ENOENT (No such file or
directory)
stat64(./Prelude.lhs, 0xbfffcfe0) = -1 ENOENT (No such file or
directory)
stat64(./Prelude.hi-boot-5, 0xbfffcfe0) = -1 ENOENT (No such file or
directory)
stat64(./Prelude.hi-boot, 0xbfffcfe0) = -1 ENOENT (No such file or
directory)
I wanted to have a look at the code to find out what's wrong, but i can't
find
the time :-(
ghci is built using http://people.mandrakesoft.com/~prigaux/ghc.spec where
%configure is ./configure
i586-mandrake-linux-gnu --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin -
-sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/
include --libdir=/usr/lib --libexecdir=/usr/lib --localstatedir=/var/lib --s
haredstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info
Any idea what's wrong?
Thanks
--
Pixel
programming languages addict http://merd.net/pixel/language-study/
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ghc-5.03 release candidate installer available (win32)
In preparation for a ghc-5.03 snapshot release, a test installer for Win32 platforms is now available: http://www.galois.com/~sof/ghc-503.msi (*) Size: 25.1 Mb. Please let me know if you run into any problems with it. thanks, --sigbjorn btw, Mike Thomas deserves a special mention for very helpful (and quick) feedback on the ghc-5.02.2 RC installer. Feedback that has been used to improve both the 5.02.2 and 5.03 installer setups. * - This installer relies on the Windows Installer runtime to operate. If, after having downloaded the above file, double-clicking on the MSI file doesn't start up the installer, the likely cause is that you don't have the runtime installed on your machine. Redistributables of the runtime can be downloaded from Microsoft: * http://www.microsoft.com/downloads/release.asp?releaseid=32831 (Windows 95,98 and ME version) * http://www.microsoft.com/downloads/release.asp?releaseid=32832 (Windows NT and 2000 version). Try installing the appropriate version before double-clicking again on the GHC installer. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ghc-5.02.2 release candidate installer available (win32)
In preparation for the upcoming release of 5.02.2, I've made available a test installer for Win32 platforms, in the hope that any packaging glitches can be caught before it's too late. The installer is available via http://www.galois.com/~sof/ghc-502-2.msi (*) It's big: 21.7 Mb. Please let me know if you run into any problems with it (or not). thanks, --sigbjorn * - This installer relies on the Windows Installer runtime to operate. If, after having downloaded the above file, double-clicking on the MSI file doesn't start up the installer, the likely cause is that you don't have the runtime installed on your machine. Redistributables of the runtime can be downloaded from Microsoft: * http://www.microsoft.com/downloads/release.asp?releaseid=32831 (Windows 95,98 and ME version) * http://www.microsoft.com/downloads/release.asp?releaseid=32832 (Windows NT and 2000 version). Try installing the appropriate version before double-clicking again on the GHC installer. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: --+ not treated as a start of a comment
Thanks, I've made Hugs98 comply with the Report. --sigbjorn - Original Message - From: Ian Lynagh [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, December 09, 2001 10:43 Subject: --+ not treated as a start of a comment If I have foo = 0 --+ 1 then ghc tells me tt.lhs:2: Variable not in scope: `--+' while the report (and hugs) believe --+ 1 is a comment. Thanks Ian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Building dlls with ghc
Hi, thanks for the report. First off, I should say that the 5.02 release didn't focus on DLL production at all, so I'm not too surprised you're coming across a gremlin or two. However, I'm not able to reproduce the break you're experiencing, my --mk-dll tests break much earlier than that. If you could provide more info on the exact steps you followed, I'd appreciate it. The nature of the bug I'm coming across is bad enough to render --mk-dll unusable with 5.02.1, I'm afraid. The next release (and the CVS repo sources) will include a fix. Thanks for pointing out the omission of 'dllwrap'; it should of course be included. hth --sigbjorn - Original Message - From: Ronald Legere [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 30, 2001 20:42 Subject: Building dlls with ghc Dear haskellers, I have been trying to build a dll that has haskell functions in it, but it doesnt seem to be working in the latest 5.02.1 windows installer version. First, ghc --mk-dll .. Doesnt do anything since it cannot find dllwrap, which doesnt come with the windows installer. Then, since I have cygwin (ver 1.3.5) i can put cygwin/bin on my path and try that, but not suprisingly that fails :) dllwrap runs fine, but then the linker complains about multiple definitions of __main, in particular from libm.a(d27.0) and libmingw32.a(gccmain.o). Note that I do routinely link up haskell executables in both dos shells and cygwin shells with no troubles though. I suppose that dll building just doesnt work at the moment, or do I just have a particulalry goofy situation... or should I just try to build my own ghc in the cygwin environment so I am not mixing things?? __ Do You Yahoo!? Buy the perfect holiday gifts at Yahoo! Shopping. http://shopping.yahoo.com ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: GHC bug
Hi, the bug fixer may have contacted you separately, but for the benefit of the mailing list and/or you, this one has now been fixed (i.e., deriving empty datatypes is not permitted). Thanks for reporting it. --sigbjorn - Original Message - From: Hal Daume III [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 30, 2001 09:24 Subject: GHC bug Prelude :reload Compiling XBar ( /nfs/isd/hdaume/projects/XBar/XBar.hs, interpreted ) ghc-5.02.1: panic! (the `impossible' happened, GHC version 5.02.1): TcGenDeriv:mk_FunMonoBind Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. This happened immediately after I change line 35 in the attached program from: data DummyHead to data DummyHead deriving (Show, Eq) I wasn't sure whether it would allow me to derive instances on a datatype with no constructors...I know this was recently added and I guess all the bugs haven't been worked out. I'm using the solaris build of ghc. -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: greencard bug
Hi,
you don't say how you processed that example .gc file with GreenCard,
but I'm guessing you used the '--target ghc' option. If that's the case,
have
a look at
http://www.haskell.org/greencard/type-sig.html#SEC-BODY
which discusses safe vs. unsafe calls -- i.e., in your case you need to
change
the %code below to %safecode. (Alternatively, use the -S option).
hth
--sigbjorn
- Original Message -
From: Chen Yu [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, November 22, 2001 03:42
Subject: greencard bug
Hi, there
I am using Greencard with Hask's foreign function export. I found
the following program can cause seg-fault. Anyone has any idea? BTW,
if I replace greencard with Hask's foreign function import, there
is no such error.
in ABC.gc:
foreign export ccall h_add h_add :: Int - IO Int
h_add a = do
putStrLn in haskell callback
return (a + 1)
%fun add :: Int - IO(Int)
%call (int a)
%code int r;
% r = c_add (a);
%result (int r)
and the result is like:
in c callback
in haskell callback
Segmentation Fault
in add.c:
_RESULT c_add(int a) {
printf(in c callback\n);
return h_add(a);
}
TIA!
--
chenyu
in Main.hs:
main = do
a - add 127
putStrLn (show a)
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: AbsCStixGen.gencode panic
The native code generator only handles 'foreign import's with a
static target, which is why you're seeing this (HEAD handles
this situation a little bit more gracefully).
Use -fvia-C (or -O, which implicitly does the same thing).
--sigbjorn
- Original Message -
From: Volker Stolz [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, November 16, 2001 10:18
Subject: AbsCStixGen.gencode panic
Beware, to reproduce you need c2hs gtk+hs!
Luckily, I can use the -O switch (does that option mean turn errors
OFF?)
to get a perfectly working binary!
ghc -c Get.lhs -o Get.o `c2hs-config --cflags` -fglasgow-exts -package
lang
ghc-5.02.1: panic! (the `impossible' happened, GHC version 5.02.1):
AbsCStixGen.gencode
typedef void ( *_ccall_fun_tys1Cc) (StgAddr, I_);
\begin{code}
module Main where
import IO
import Maybe
import Monad
import Foreign
import CString
import GModule
type Fun = CString - Int - IO ()
foreign import dynamic unsafe iterator__ :: FunPtr Fun - Fun
main :: IO ()
main = do
withModule (Just .) simple ModuleBindOnLoad $ \ mod - do
funptr - moduleSymbol mod simple
when (isNothing funptr) $ error fo!
let res = iterator__ (castPtrToFunPtr (fromJust funptr))
withCString hello $ \ str - res str 1
return ()
\end{code}
--
Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: HDirect (CVS version) - some bugs
Thanks for the bug report. I've checked in a fix for 1), but for 2), I suggest instead of doing void pj_set_finder( const char *(*)(const char *) ); you express this as typedef [string]char* (*StringTrans) ([in,string]char* arg1); void pj_set_finder([in]StringTrans arg); as HDirect doesn't currently handle 'const' qualifiers as well as it could. --sigbjorn - Original Message - From: Mike Thomas [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Sigbjorn Finne [EMAIL PROTECTED] Sent: Wednesday, November 07, 2001 15:42 Subject: HDirect (CVS version) - some bugs Hi there. Attached is a small zip file containing some idl and header files which are meant to define an interface to Frank Warmerdam's map projection library. The problems can be reproduced by unzipping, going to the top level directory and running make. I am using Windows NT GHC 5.02 and CVS version of HDirect. 1. The C stub code (Proj.c) generated for structures defined in the idl with lower-case leading characters has upper case leading characters eg: projXY in the IDL is converted to ProjXY. I have worked around this by including a header file (nameconvert.h) with macros which change the names back to those used in the library headers, but this is messy. 2. The Haskell code (Proj.hs) contains some strange definitions to do with a datatype IHC_TAG_0, which causes the errors below when compiled. The datatype is associated with a function which takes another function as an argument: void pj_set_finder( const char *(*)(const char *) ); Cheers Mike Thomas --- IHC_TAG_0 error messages ghc -c -package lang -package com -fglasgow-exts -fvia-C Proj.hs -o proj_hs.o Proj.hs:338: Couldn't match `PrelMaybe.Maybe (PrelBase.Char - PrelIOBase.IO PrelBase.Char)' against `IHC_TAG_0' Expected type: PrelMaybe.Maybe (PrelBase.Char - PrelIOBase.IO PrelBase.Char) Inferred type: IHC_TAG_0 In the third argument of `HDirect.marshallref', namely `arg10' In a 'do' expression pattern binding: arg10 - HDirect.marshallref (HDirect.allocBytes (PrelReal.toInt sizeofI HC_TAG_0)) (HDirect.writeunique (HDirect.allocBytes (P relReal.toInt sizeofIHC_TAG_0)) writeIHC_TAG_0) arg10 make: *** [proj_hs.o] Error 1 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Happy generates uncompilable files
Hi,
couple of things:
* you don't have to side-effect mk/config.mk{.in} to make
any changes to the definitions in there. Just create your own
mk/build.mk and add definitions of variables you need for
your build tree to work/behave as expected. The build.mk
defns override those in mk/config.mk
(see 5.3 of the GHC Building Guide for more).
* the break you're seeing is due to the GHC native code generator
not being able to handle Int16-sized values internally. My suggested
fix for the problem you're running into would be not to change
the options given to Happy, but to GHC - i.e., have it generate code
via C (== add -fvia-C to rename/ParseIface_HC_OPTS and
parser/Parser_HC_OPTS in ghc/compiler/Makefile).
I've committed the latter fix.
hth
--sigbjorn
- Original Message -
From: Josef Svenningsson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, November 08, 2001 08:15
Subject: Happy generates uncompilable files
Hi!
Here's a small patch to fptool/mk/config.mk.in which I need for the
compiler to compile smoothely on my sparc:
*** config.mk.inThu Nov 8 17:12:46 2001
--- ../../fptools/mk/config.mk.in Wed Nov 7 16:23:03 2001
***
*** 833,843
#
# Options to pass to Happy when we're going to compile the output with
GHC
#
- ifeq $(i386_TARGET_ARCH) 1
GHC_HAPPY_OPTS= $(shell if ( test `echo $(HAPPY_VERSION)
| sed -e s/\(.*\)\..*/\1/g` -gt 1 || test `echo $(HAPPY_VERSION) |
sed -e s/.*\.\(.*\)/\1/g` -ge 9 ); then echo -agc; else echo -g; fi)
- else
- GHC_HAPPY_OPTS= -gc
- endif
#
# Stuff from fptools/literate
--- 833,839
Why? Because with the -a flag happy generates files which uses the
Int16Rep function. This is only implemented for x86. :-(
Could you please add this patch? It would make my life a lot easier.
Cheers,
/Josef
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Building GHC 5.02 on Solaris x86
Simon Marlow [EMAIL PROTECTED] writes: Having just looked at the code, it seems we could recover the platform-independentness in the I/O library with just a small amount of wrapperage: most of the offending code is in PrelPosix.hsc, with a few #const's scattered around PrelHandle and PrelIO, and none of the affected areas are particularly performance-critical. Also needing wrappers are Time, CPUTime, Directory System. I'd say stop there, though - this is purely to make bootstrapping on a new OS easier, so we only need to apply the no-tool restriction to libraries needed by the compiler. Good, let's sort this one out. ghc/compiler/ has its fingers deep in the pie that is hslibs/, so presumably the restriction applies there also? I'll happily convert some of these files (once I know what wrapper story you have in mind); let me know. --sigbjorn ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Building GHC 5.02 on Solaris x86
Yuck. If this isn't enough to convince people that hsc2hs is not an appropriate tool (at least in the context of the Prelude and hslibs/), than I don't know what is. It commits to a particular platform at too early a stage -- details of C header files are often best left toC source files for C compilers to process and deal with, not Haskell. If possible, keeping your Haskell sources plat-indep. is a good goal to have, and I don't see any fundamental reasons why that can't be done here (indeed, the previous Prelude cbits/ setup was fairly close to achieving this). So, bringing back the solution of having manually written C wrapper functions which platform-independent Haskell source files will call out to, would be preferable (in short, avoid the use of hsc2hs *or any other extra tool* alltogether). I'm willing to make the necessary changes. --sigbjorn As another data point, this is also an issue when booting under OpenBSD x86. I suspect anyone with a version of the glibc headers on a Linux box different to those used to bake the supplied .hc / .hs files are also at risk of running into problems. - Original Message - From: Simon Marlow [EMAIL PROTECTED] To: Ian Lynagh [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, October 29, 2001 03:08 Subject: RE: Building GHC 5.02 on Solaris x86 Doh, I have several times got further than I thought but didn't realise it as I didn't notice it had made a ghc-5.02 binary! Here's my latest problem, anyway - I don't suppose it could be caused by the hc files being generated under a different OS with different magic numbers could it? Ah yes, I forgot about that. Ken Shan came across the same problem when porting to Alpha. To generate a Solaris-friendly set of hc files for the libraries you need to do this: for each .hsc file, take the C output from hsc2hs on a Linux box (use --no-compile to get the _hsc_make.c file), and compile/run it on your Solaris box to get the .hs file. Take the .hs file back to Linux to generate the .hc file. You will probably have to generate a full set of .hc files, including the compiler. That means doing a 2-stage build on Linux using the .hs files generated on Solaris as above. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Building GHC 5.02 on Solaris x86
Alastair David Reid [EMAIL PROTECTED] writes: So, bringing back the solution of having manually written C wrapper functions which platform-independent Haskell source files will call out to, would be preferable (in short, avoid the use of hsc2hs *or any other extra tool* alltogether). I'm willing to make the necessary changes. You started by objecting to using a tool that commits your code to a platform too early. I'm in complete agreement. But now you seem to be objecting to using any tools at all. This seems excessive. Why not do one of: [..suggestions on what kind of tool to provide..] (This is all on the assumption that the amount of code we're talking about is significant enough to care. I have the impression that it is but could be wrong.) Yep, I'm of the humble(?) opinion that it is not. Minimising your tool dependencies is always something to keep in mind too. But let not that be the main point - the main point was that this problem needs to be addressed, tool or no tool. I offered a no-tool solution which has worked well in the past. --sigbjorn ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: GHC-5.02/Win32: problems compiling with -prof and -package
Nothing deep going on, the profiling interface files for the 'util' package are simply just missing from the 5.02 distribution. --sigbjorn - Original Message - From: P Jensen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 12, 2001 14:00 Subject: GHC-5.02/Win32: problems compiling with -prof and -package Hi GHCers -- I'm running GHC 5.02 on Win32 (2000 Professional), and having problems compiling with the -prof option. There seems to be some sort of conflict between the -package option and the -prof option. For instance, this program: module Main where main = putStr Hello, world.\n compiles fine with: ghc -prof -auto-all -o t1 t1.lhs and this program: module Main where import GetOpt main = putStr Hello, world.\n compiles fine like this: ghc -package util -o t2 t2.lhs but when compiled like this: ghc -prof -auto-all -package util -o t2 t2.lhs it results in an error: t2.lhs:2: failed to load interface for `GetOpt': Could not find interface file for `GetOpt' My guess is that this is some sort of configuration problem on my end, or a grave misunderstanding of how to invoke the compiler/profiler. Does anyone have any ideas? Cheers, Paul ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bug in GHC 5.02
To make this panic go away, try adding the option
"-fvia-C" to your GHC
command line.
(GHC could give a better error msg here, and
indicate that you have to
use -fvia-C with code that (still) uses
_casm_.)
hth
--sigbjorn
- Original Message -
From:
Monique Louise
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED] ; [EMAIL PROTECTED]
Sent: Tuesday, October 09, 2001
12:41
Subject: Bug in GHC 5.02
I am writing to report a bug I have found in GHC
version 5.02. The problemis that I tried to compile a .hs file
which camewith Green Card's library and the following message
appeared:
"panic! (the 'impossible' happened, GHC version
5.02): Native code generator
can't handle foreign call {-_ccall-}__casm ``do {void *
arg1;
arg1 = (void
*)%0;
do {free(arg1);
} while(0);} while(0);'' arg1Please report it as a compiler bug to
[EMAIL PROTECTED],or
http://sourceforge.net/projects/ghc/."
Othermessageslikethe one above
appeared when I tried to compile other files which used foreign
procedures.
Monique Monteiro
Re: GHC 5.02 Win32
Yes, non-interactive uses of the Win32 library appear to be in a non-working state (at least with my copy of ghc-5.02, don't know if there's been any stealth updates to the installer binary.) As a stop-gap measure, replace ghc-5.02's libHSwin32.a (after having saved it away) with the one contained in http://www.galconn.com/~sof/HSwin32.zip and try again. Hopefully this can be fixed in the installer proper.. (The cause of it all is that libHSwin32.a lacks a pair of _stub.c files which contains the code that takes care of the window/dialogue callbacks into Haskell). hth --sigbjorn - Original Message - From: Mike Thomas [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, October 07, 2001 19:58 Subject: GHC 5.02 Win32 Hi there. Congratulations on 5.02 - a lot of work in that one for you. The web site Win32 example program doesn't link due to an undefined reference to Win32Window_dfQU which is defined in HSwin321.o. Although that file is listed in the package.conf entry for win32, it (and it's presumed companion HSwin322.o) does not appear in the verbose output from ghc's call to ld (an extract is below) when -package win32 is passed to ghc. The win32 libraries are there, however. Cheers Mike Thomas. . e:\ghc\ghc-5.02\gcc-lib\ld.exe -Bdynamic -o hello.exe -u _Addr_Azh_static_info -u _PrelBase_Izh_sta tic_info -u _PrelBase_Czh_static_info -u _PrelFloat_Fzh_static_info -u _PrelFloat_Dzh_static_info -u _PrelPtr_Ptr_static_info -u _PrelWord_Wzh_static_info -u _PrelInt_I8zh_static_info -u _PrelInt_I16z h_static_info -u _PrelInt_I32zh_static_info -u _PrelInt_I64zh_static_info -u _PrelWord_W8zh_static_i nfo -u _PrelWord_W16zh_static_info -u _PrelWord_W32zh_static_info -u _PrelWord_W64zh_static_info -u _PrelStable_StablePtr_static_info -u _PrelBase_Izh_con_info -u _PrelBase_Czh_con_info -u _PrelFloat_ Fzh_con_info -u _PrelFloat_Dzh_con_info -u _PrelPtr_Ptr_con_info -u _PrelStable_StablePtr_con_info - u _PrelBase_False_closure -u _PrelBase_True_closure -u _PrelPack_unpackCString_closure -u _PrelIOBas e_stackOverflow_closure -u _PrelIOBase_heapOverflow_closure -u _PrelIOBase_NonTermination_closure -u _PrelIOBase_BlockedOnDeadMVar_closure -u _PrelWeak_runFinalizzerBatch_closure -u ___stginit_Prelude -u _PrelMain_mainIO_closure -u ___stginit_PrelMain e:/ghc/ghc-5.02/gcc-lib/crt2.o -Le:/ghc/ghc-5.02 -Le:/ghc/ghc-5.02/gcc-lib hello.o -lHSwin32 -luser32 -lgdi32 -lwinmm -lkernel32 -ladvapi32 -lHSlang -lHSlang_cbits -lHSstd -lHSstd_cbits -lwsock32 -lmsvcrt -lHSrts -lm -lwin mm -lwsock32 -lgmp -lmingw 32 -lgcc -lmoldname -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lming w32 -lgcc -lmoldname -lm svcrt e:/ghc/ghc-5.02/libHSwin32.a(Win32Window__106.o)(.text+0x2ba)://c/tmp/ghc169 2.hc: undefined referenc e to `Win32Window_dfQU' .. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc-5.00.2 -fvia-C: undeclared symbols
hi, you're running into trouble with some expeditious hacks that were put into TclHaskell to make it work with ghc-4.xx. The following change will make it compile with ghc-5.xx - have Check.h now contain: extern StgTSO *run_queue_hd; #if __GLASGOW_HASKELL__ = 408 extern StgTSO *MainTSO; /* temporary hack */ #define END_TSO_QUEUE ((StgTSO *)(void*)END_TSO_QUEUE_closure) #endif hth --sigbjorn - Original Message - From: Chris Dornan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, August 27, 2001 13:50 Subject: ghc-5.00.2 -fvia-C: undeclared symbols Hi, I am trying to compile TclHaskell (latest on haskell.org) with ghc-5.00.2 on Redhat 7.1 with an x86 thingie, but run into problems in trying to compile a low-level module that calls out to C. ghc -fglasgow-exts -recomp -dcore-lint -syslib concurrent -fvia-C '-#include Check.h' -c -ohi TclCompatibility.hi TclCompatibilityGhc.hs /tmp/ghc4365.hc: In function `s141_fast1': /tmp/ghc4365.hc:157: `END_TSO_QUEUE_closure' undeclared (first use in this function) /tmp/ghc4365.hc:157: (Each undeclared identifier is reported only once /tmp/ghc4365.hc:157: for each function it appears in.) I have noticed that ghc-5.00.2 seems to be more reliable with the x86 native generator but I don't think I can avoid it here as the module is calling out to C. Is this a known problem? Can anyone suggest a work-around? Cheers, Chris Dornan [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc uses C:\TEMP for temporary files, rather than %TEMP
I've had this very change sitting on my disk for quite a while; now checked in. Unless further testing uncovers anything really bad, 5.02 should have it included. --sigbjorn - Original Message - From: Reuben Thomas [EMAIL PROTECTED] To: Moore, Paul [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, August 17, 2001 06:08 Subject: Re: ghc uses C:\TEMP for temporary files, rather than %TEMP I have my TEMP variable set to C:\WINNT\TEMP (Windows 2000). I do not have a C:\TEMP directory. However, when I run ghc on a trivial source file, I get ghc -o main main.hs ghc: panic! (the `impossible' happened, GHC version 5.01): Failed to open or write code output file C:/TEMP/ghc1644.s Like it says in the instructions, you have to have C:\TEMP. Sorry; this is hardwired at the moment. GHC should use %TEMP (or better, the Win32 GetTempPath() API call) to save intermediate files. That sounds like a good idea. I'll look into it. Despite being the Windows maintainer, I'm not a Win32 expert. -- http://sc3d.org/rrt/ | aphorism, n. a wise lie ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: BUGS (2): Win32 ghc and Win98
Reuben Thomas [EMAIL PROTECTED] writes: BUG 2: Under Windows 98 Sigbjorn's example Win32 hello world program displays but then hangs when the window close icon is clicked. Works OK under NT, and can be closed under Windows 98 by ^C in the terminal window. I'm unable to repro this problem with Win98SE and a GHC built from current CVS repository sources. NOFIX 2: Unfortunately I haven't got around to working on this one yet. FIX 2: Upgrade to Win2K or XP (or better, Linux, even though this would put me out of a job!). Unfortunately, we don't have Win98 around here, and getting things working in the (relatively sane) Win2K environment is bad enough. I'll be delighted to implement any solution up with which you come. VMWare is great for performing this kind of platform testing. --sigbjorn ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RtsFlags.h
Defining an app-local version of defaultsHook() is currently not possible using just a binary distribution. i.e., to do something interesting inside of defaultsHook(), you need to side-effect RtsFlags (which has type RTS_FLAGS). RTS_FLAGS is defined in RtsFlags.h, which is not to be found in a binary dist. (= RtsFlags.h (or a subset thereof) should perhaps be moved from ghc/rts to ghc/includes/ ?) --sigbjorn ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Zarjaz have a problem with Dynamic Libraries
Hi, I've checked in a fix for this to the CVS repo (was bitten by the very same problem here), so hopefully a release of ghc-win32 will have that fix included at some stage. --sigbjorn Krasimir Angelov [EMAIL PROTECTED] writes: Problem while I use Dynamic libraries from C side. Prims.o, grid.o and pack.o are compiled C modules They uses Win32 API. - DUMP C:\WinHaskell2ghci prims.o grid.o pack.o WinStub.o -lgdi32 -luser32 -lkernel32 -lcomctl32 ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.01, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package std ... linking ... done. Loading object (static) prims.o ... done Loading object (static) grid.o ... done Loading object (static) pack.o ... done Loading object (static) WinStub.o ... not found Loading object (dynamic) comctl32 ... done Loading object (dynamic) kernel32 ... done Loading object (dynamic) user32 ... done Loading object (dynamic) gdi32 ... done Prelude Prelude :l WinHaskell can't find module `Addr' Prelude :s -package lang Loading package lang ... linking ... ocResolve_PEi386: pack.o: unknown symbol `_GetWindowLongA' ghc.exe: panic! (the `impossible' happened, GHC version 5.01): resolveObjs: failed Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: HDirect example compilation problem
Mike Thomas [EMAIL PROTECTED] writes:
After compiling the HDirect 0.17 sources using GHC 4.08.2 and the latest
Cygwin internet distribution (some small mods made to deal with Cygwin
B20isms in the C source code):
dlltool --output-lib liburlmon.a --def urlmon.def --dllname urlmon.dll -k
. ./../src/ihc -c HtmlDialog.idl -o HtmlDialog.hs
//c/ghc/ghc-4.08.2/bin/ghc -syslib com -fglasgow-exts -L. -lurlmon-c
HtmlDialog.hs -o HtmlDialog.o -osuf o
panic! (the `impossible' happened):
getRegister(x86)
(Prim {-__stdcall-}__dyn_ccall_GC "" Temp(B0StgAddr) Temp(B1StgAddr)
Temp(B2StgAddr) Temp(B3StgAddr) Temp(B4StgAddr) Temp(B5StgAddr))
Hi,
the NCG isn't quite up to handling the FFI, so you need to add -fvia-C to
HC_OPTS in the Makefile (Oh, and -static too, just to be sure.)
This and a couple of other details surrounding the examples/ directory
was something I didn't get around to doing for 0.17. Hope to have this
fixed for 0.18, but in the meantime, attached is a missing little header
file from examples/html-dialog/, which you'll need to successfully
build that example.
hth
--sigbjorn
HtmlDialog.h
Re: green-card in cvs does not compile [low priority]
[EMAIL PROTECTED] writes: There seems to be a problem in the gc parser in the cvs (updated two minutes ago; see the output below). I am using ghc-4.08.1 and happy1.9. I do not need gc myself at the moment, but I am happy to try any magic spells you give me in case it's a problem with my setting (which strikes me as unlikely, though). Thanks, I've been meaning to check in a fix for this for a while. Happy 1.9 (and later) imposes a restriction on the possible types a monadic lexer can have, which causes a problem for GC's state-based lexer. I've just committed a fix - should work with pre and post happy-1.9. --sigbjorn ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Segmentation fault in program
The problem is indeed that the wrong __init_Foo is being passed to startupHaskell. No, that's not it. I've been able to repro this with __init_ConvertProxy too - did you test it? (This is with 4.08.1 on a Win2k box.) --sigbjorn ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Segmentation fault in program
I'm able to reproduce this here too -- forwarded to glasgow-haskell-bugs; I'm no longer involved debugging GHC bits. --sigbjorn - Original Message - From: "T.J. Brown" [EMAIL PROTECTED] To: "Sigbjorn Finne" [EMAIL PROTECTED] Sent: Monday, February 12, 2001 19:21 Subject: Re: Segmentation fault in program After making the changes suggested below and updating the GHC driver script to fix the -no-hs-main bug, my program will successfully complete when processing a small amount of data. When processing larger amounts of data, however, it will crash with a segmentation fault or print "EVACUATED object entered". If I increase the size of the heap with "+RTS -Hsize" the program will complete successfully. It doesn't seem like the garbage collector is doing the right thing. Is there something I need to do to enable the garbage collector to free memory between subsequent calls to the my Haskell function (Convert)? Thanks, T.J. --- Sigbjorn Finne [EMAIL PROTECTED] wrote: Hi, your converttst.c contains the following decl: extern void startupHaskell (int argc, char* argv[], void* rootMod); void* __init_Main; That won't work, as the root module argument needs to point to something valid. Rewrite it to: extern void startupHaskell (int argc, char* argv[], void* rootMod); extern void* __init_Convert; and substitute __init_Main with __init_Convert wherever it is used in the C code. __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Segmentation fault in program
"T.J. Brown" [EMAIL PROTECTED] writes: I'm trying to write a program (in C) that calls a function that is implemented in Haskell. ... The problem I'm seeing is that depending on the size of the buffer, the program segmentation faults. I don't see any obvious reason that this is happening so I'm wondering if something isn't going wrong during the compilation. Hi, your converttst.c contains the following decl: extern void startupHaskell (int argc, char* argv[], void* rootMod); void* __init_Main; That won't work, as the root module argument needs to point to something valid. Rewrite it to: extern void startupHaskell (int argc, char* argv[], void* rootMod); extern void* __init_Convert; and substitute __init_Main with __init_Convert wherever it is used in the C code. However, if you recompile and link, I believe you'll see it crashing even more regularly - I suspect this is due to a bug in the GHC RTS (at least 4.08.1's, don't know if 4.08.2 has fixed this) Attached is a simpler program that shows up the problem. Also, is there a better way of passing a buffer between C and Haskell? For instance, is there a way to convert the buffer into a list automatically? Yes, you can simplify Convert.convert a little, but your example highlights a dark corner that HaskellDirect doesn't implement fully, i.e., dependent arguments in Haskell server proxies. You *should* be able to just say [pure] void convert([in,length_is(len)] unsigned long *inBuf, [in] int len, [out,length_is(len*4)] unsigned char *outBuf); and have the generated Haskell code expect Convert.convert to have the signature ([Word32] - [Word8]) - I'm working on implementing this at this very moment. --sigbjorn test.tar.gz
Re: Possible bug in ghc 4.08.1, I leave it to you
Martin Norbck [EMAIL PROTECTED] writes: Hi! a :: Show c = c - Integer a err = if b 0 then error (show err) else 1 b :: Integer b = a "dummy" This program (although it doesn't do much good), type checks perfectly in hugs. (I have a larger version which actually does some good as well). But in ghc 4.08.1 I get the following error. Mismatched contexts When matching the contexts of the signatures for `b' and `a' (the signature contexts in a mutually recursive group should all be identical) But where is this requirement in the Haskell report? It might be that I don't understand what the report says, but this seems like a perfectly good use to me. See 4.5.2 of the report and section 11.6.3 of Mark Jones' "Typing Haskell in Haskell" (http://www.cse.ogi.edu/~mpj/thih/ ) paper for a discussion of the issue. The conclusion there is that the H98 restriction on the shape of signature contexts in mut-rec groups is overly restrictive. Last I heard (about 12 months ago) was that Simon PJ _might_ consider treating this as a bug in the H98 report change it. hth --sigbjorn ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: fptools/configure thinks happy 1.10 1.9
Volker Stolz [EMAIL PROTECTED] writes: My happy is 1.10, everything fresh from cvs: --- checking for happy... /home/stolz/Linux/haskell/ghc-4.08.1/bin/happy checking for version of happy... Happy version 1.9 or later is required to compile GHC. --- And in a sense, it is right. I'd really like to come up with a fix, but I guess... [...perl silliness deleted..] If you assume that the version string is of the form X.Y, the following test should do the trick: if ( test `echo "$fptools_cv_happy_version" | sed -e "s/\(.*\)\..*/\1/g"` "-eq" "1" test `echo "$fptools_cv_happy_version" | sed -e "s/.*\.\(.*\)/\1/g"` "-lt" "9" ); then substitute it for the usage of 'expr' in the FPTOOLS_HAPPY macro in aclocal.m4 rebuild the configure script, i.e., I haven't committed this tweak. --sigbjorn ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: documentation buglet in green card's online docs
Ketil Malde [EMAIL PROTECTED] writes: Incredibly tiny nit, but in the final section about compiling stubs, I believe you mean -fPIC as the gcc option (the documentation says -fPCI, which isn't something gcc recognizes). Thanks, fixed. You might also want to point out that debian packages are available for apt-get'ting, at least you run woody. If someone could supply me with a valid apt source for it (or is it part of the HamRadio tree now?), adding it shouldn't be a problem. Please note that the GreenCard home page has moved; it's now at http://www.haskell.org/greencard The old location has got a re-direct to the new one, so the transition will hopefully be smooth one. Also, in the future, please report any GC bugs to me directly. thanks, --sigbjorn ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
