ghc-6.4 bootstrap problem with System/CPUTime_hsc.c
I have been attempting to bootstrap ghc-6.4 on a Solaris 2.8/SPARC system with no previous version of ghc installed. I'm currently stuck at System/CPUTime_hsc.c. The build fails at the following point: $ distrib/hc-build --enable-hc-boot-unregistered [ many successful lines skipped ] ==fptools== gmake boot -wr; in /home/doughera/src/ghc/ghc-6.4/libraries/base touch GHC/PrimopWrappers.hs gmake[2]: *** No rule to make target `System/CPUTime_hsc.c', needed by `depend'. Stop. I don't think the problem is specific to Solaris. I run into the same error trying to bootstrap on a Debian Linux/SPARC system with no previous version of ghc installed. Any suggestions? (Other than finding a binary package for this system, of course. I know about that option.) Thanks, -- Andy Dougherty [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: [ ghc-Bugs-1175454 ] System.system fails on windows98se, also disables ghci's :!
On 05 April 2005 20:33, Claus Reinke wrote: Let me see if I get the call-chain correct (System.-prefix omitted): Cmd.rawSystem - Process.runProcess - Process.Internals.runProcessWin32 Cmd.system - Process.runCommand - Process.Internals.commandToProcess + Process.Internals.runProcessWin32 The first thing I notice is that commandToProcess doesn't do much (well, now it tries to find a command interpreter, but it does no translation) - both variants go through runProcessWin32, which calls Process.Internals.translate! Is that intended?? It looks like a bug to attempt counter-translation for Cmd.system? If you look closely, you'll see that translate isn't applied to the argument to runCommand. There's no double-translation going on, we just pass the command line directly to cmd.exe/command.com. rawSystem needs to convert the [String] parameters into a single string for passing to CreateProcess. I'm pretty sure that translate is doing the right thing here, at least if the target process is using the standard command-line parser from Microsoft's C runtime. It seems that command.com has non-standard command-line parsing, so it won't work with rawSystem. In fact on Windows, runCommand is really more raw than rawSystem, because it does no translation. The translation could be made to avoid using quotes in cases where quotes aren't necessary. But you can't avoid quoting in general, so this wouldn't be a proper fix. So I propose the following: - we document that rawSystem doesn't work well if you're invoking command.com or cmd.exe on Windows: use runCommand insteead. - we could provide a way to access runProcessWin32 directly, which gives you a more raw interface to CreateProcess on Windows (non-portable, of course). As an experiment, I created my own version of the rawSystem-chain, replacing the call to translate for the args in runProcessWin32 with a call to id, and that seems to be sufficient to solve this problem: ... snip... whether this creates any other issues I don't know:-) It'll break invoking programs other than command.com with rawSystem. We spent quite a bit of time getting this right - the best way to test it is to build your own 'echo' program, and try invoking that using rawSystem passing arguments involving quotes, spaces and backslashes. The echo program should see the arguments exactly as you passed them to rawSystem. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: exposed package exposes dependent packages
On 06 April 2005 00:06, Duncan Coutts wrote: On Tue, 2005-04-05 at 23:34 +0100, Simon Marlow wrote: Well it turns out that we had another package installed that depends on the util package (cabal-0.5 as it happens) and that package is exposed by default. It seems that this implicitly exposes the util package. This is the right behaviour, although I agree it's a little confusing. The util package has not been exposed as a result of being depended on by cabal-0.5, but GHC has correctly inferred that it is part of the program, and so its modules cannot clash with any others in the program. But it's not part of the program. In our test program we do not import any module from the dummy package (which is the exposed package that depends on util). Our example was compiling happy. happy does not import anything from cabal-0.5 and yet it was hit by this problem. Unless we consider 'part of the program' to be all modules in all exposed packages (and all modules in 'efectively exposed' packages like util via the cabal-0.5 dep). You're asking GHC to decide which modules the program depends on, in order to figure out which packages are part of the program, rather than just starting from the list of exposed packages. Hmm, that might be possible... we could eagerly report module clashes in the exposed packages, but only report module clashes in the hidden packages when we know which ones are required. If this is not a bug, the only thing we can do is make sure we never create an ebuild for anything that installs an exposed package that depends on one of the old hslibs packages. Otherwise several other unrelated programs will fail to build. The documentation does describe this (section 4.8.1): There must be no overlaps in the modules provided by all of the exposed packages, and the packages they depend on, and so on. it doesn't mention the modules of the program though. Perhaps it should, I'm open to suggestions for better wording. So is it all modules provided by exposed packages or all modules included (directly or indirectly) in the program? It is: modules in the program (or current package) + modules from exposed packages + modules from all packages transitively reachable from the dependencies of the exposed packages. It would be nice if the error message said something like util-1.0 is included because it is a dependency of That would help. We were left wondering how on earth util was getting included into the program. I'm surprised that you could use -ignore-package util, I would have expected that to cause an error due to the dependency from cabal to util. That might be a bug - can you confirm? Yes indeed. Until recently we compiled happy with -ignore-package util to work around this issue. Our new solution is to declare cabal-0.5 to be incompatible with GHC 6.4. Ah, I remember now: -ignore-package also magically ignores all packages that depend on the ignored package. It was done this way so that you could recompile a package down at the bottom of the dependency graph (eg. base) without having to know all the packages that currently depend on it. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Broken Web links in ghc-6.4 top-level README
On 05 April 2005 18:03, Andy Dougherty wrote: Attempting to read the installation instructions from the site suggested in the README file in the root directory results in Not Found. Specifically, it points to: http://www.haskell.org/ghc/docs/latest/html/building/building-guide.html Sorry, that's an old version of the link. I've added a redirect so it should work now. This actually seems to be a general problem -- on the main http://www.haskell.org/ghc/ front page, for example, there is a link to the mailing lists: http://www.haskell.org/ghc/docs/latest/html/users_guide/introduction-ghc .html#MAILING-LISTS-GHC that also comes back Not Found. I eventually found the correct name of the mailing list (obviously) but it makes for a bit of a frustrating initial experience. You've probably got an old cached copy of the front page, that link was updated a few weeks ago (but it's in a server-side include which doesn't seem to report the modified date properly). See if you can force a refresh. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: exposed package exposes dependent packages
Our example was compiling happy. happy does not import anything from cabal-0.5 and yet it was hit by this problem. Unless we consider 'part of the program' to be all modules in all exposed packages (and all modules in 'efectively exposed' packages like util via the cabal-0.5 dep). You're asking GHC to decide which modules the program depends on, in order to figure out which packages are part of the program, rather than just starting from the list of exposed packages. Hmm, that might be possible... we could eagerly report module clashes in the exposed packages, but only report module clashes in the hidden packages when we know which ones are required. This sounds like a good compromise to me. It would allow to have some packages exposed which are not particularly well-behaved (i.e., pollute the name space), but you pay the price only when you're actually using the package. The current situation is unfortunately very fragile. An exposed package that is accidentally added to the system can break the compilation of completely unrelated programs. It'd be great if you could make this change in ghc. Cheers, Andres ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Broken Web links in ghc-6.4 top-level README
On Wed, 6 Apr 2005, Simon Marlow wrote: On 05 April 2005 18:03, Andy Dougherty wrote: Attempting to read the installation instructions from the site suggested in the README file in the root directory results in Not Found. Specifically, it points to: http://www.haskell.org/ghc/docs/latest/html/building/building-guide.html Sorry, that's an old version of the link. I've added a redirect so it should work now. Thank you. This actually seems to be a general problem -- on the main http://www.haskell.org/ghc/ front page, for example, there is a link to the mailing lists: http://www.haskell.org/ghc/docs/latest/html/users_guide/introduction-ghc .html#MAILING-LISTS-GHC that also comes back Not Found. I eventually found the correct name of the mailing list (obviously) but it makes for a bit of a frustrating initial experience. You've probably got an old cached copy of the front page, that link was updated a few weeks ago (but it's in a server-side include which doesn't seem to report the modified date properly). See if you can force a refresh. Thanks again. It's not cached on my system, but I suppose it might be cached somewhere upstream of me. Oh well, it's no big deal. -- Andy Dougherty [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Bug in hDuplicateTo in GHC 6.4
Hello. The following program demonstrates the bug: import GHC.Handle import GHC.IOBase import GHC.Conc import IO main = do h - openFile /tmp/out WriteMode hDuplicateTo h stdout fdh - getfd h fdstdout - getfd stdout hPutStrLn stderr (h: ++ show fdh ++ \nstdout: ++ show fdstdout) hClose h putStrLn bla getfd h@(FileHandle _ mvar) = do h__ - takeMVar mvar let fd = fromIntegral (haFD h__) putMVar mvar h__ return fd The output: h: 1 stdout: 1 dup: stdout: hPutChar: invalid argument (Bad file descriptor) After hDuplicateTo, both handles use the same file descriptor. Closing one of them invalidates the file descriptor underneath the other. The documentation isn't completely clear about what hDuplicateTo is supposed to do. But from the name and the comment in base/GHC/Handle.hs I conclude that it should make two handles which use two different fds which refer to the same file, like dup2 does. Bye, V.W. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Bug in hDuplicateTo in GHC 6.4
On 06 April 2005 16:16, Volker Wysk wrote: The following program demonstrates the bug: import GHC.Handle import GHC.IOBase import GHC.Conc import IO main = do h - openFile /tmp/out WriteMode hDuplicateTo h stdout fdh - getfd h fdstdout - getfd stdout hPutStrLn stderr (h: ++ show fdh ++ \nstdout: ++ show fdstdout) hClose h putStrLn bla getfd h@(FileHandle _ mvar) = do h__ - takeMVar mvar let fd = fromIntegral (haFD h__) putMVar mvar h__ return fd The output: h: 1 stdout: 1 dup: stdout: hPutChar: invalid argument (Bad file descriptor) That's a bug, now fixed. Thanks for the report. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
