Re: [GHC] #1437: Build failures on Mac OS X 10.5
#1437: Build failures on Mac OS X 10.5 --+- Reporter: [EMAIL PROTECTED] |Owner: Type: bug| Status: new Priority: normal |Milestone: 6.8 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: MacOS X| Testcase: Architecture: x86| --+- Comment (by [EMAIL PROTECTED]): I built with -keep-hc-files, but could not figure out which of the three files with sbqE_info was the one involved in the crash. I tried disassembling the .o files containing sbqE_info, but none of them contains the code that is crashing. The code that is crashing is in the binary of the compiler (of course), but I can't figure out which .o file it came from. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1437 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1437: Build failures on Mac OS X 10.5
#1437: Build failures on Mac OS X 10.5 --+- Reporter: [EMAIL PROTECTED] |Owner: Type: bug| Status: new Priority: normal |Milestone: 6.8 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: MacOS X| Testcase: Architecture: x86| --+- Comment (by guest): Running the command line: ghc -H16m -O -fglasgow-exts -cpp -Iinclude -#include HsBase.h -funbox- strict-fields -package-name base-2.1.1 -O -Rghc-timing -fgenerics -fgenerics-c GHC/Float.lhs -o GHC/Float.o -ohi GHC/Float.hi instead of using the built stage1 compiler succeeds, so the problem is definitely that the built stage1 compiler has something wrong with it. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1437 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1463: Module → Package loo kup in ghc-pkg?
#1463: Module → Package lookup in ghc-pkg? --+- Reporter: [EMAIL PROTECTED] |Owner: Type: feature request| Status: new Priority: normal |Milestone: 6.10 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown| Testcase: Architecture: Unknown| --+- Changes (by simonmar): * milestone: = 6.10 Comment: in fact, i thought it should be one of the things cabal ought to be good at, but looking through the haddocks for Distribution.*, i seem to be running around in circles: is there any standard way to get at the installed package.conf files, or directly at the InstalledPackageInfos?? there's a getInstalledPackages, but that only gives me the PackageIdentifiers?, with no obvious way to go further? This is parly by design. Cabal interacts with the package database only using the `ghc-pkg` tool (`hc-pkg` in general), the idea being that the representation and location of the package database can be compiler- dependent. There's no requirement that the package database is stored in the way that GHC does it, or even that the package database contains `InstalledPackageInfo`s - a compiler might want to add extra information about each package. In fact, GHC already has an alternative way to store the package database (files in `package.conf.d`). To get an `InstalledPackageInfo` for a given package, you have to use `ghc-pkg describe` and parse the output (I believe it should work). Parsing `package.conf` directly is non-portable, and risks breakage in the future. We could add a way to get the `Read/Show` version of an `InstalledPackageInfo`, if that would make it easier. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1463 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: skipping module in .cabal
Just to make this 100% explicit: * Cabal uses ghc --make to build a bunch of .o files (including Match.o) * Cabal then links the .o files that are listed in dm.cabal (as exposed or other) to make a .a file. This list accidentally excludes Match.o * Cabal copies the .a file and the .hi files listed in dm.cabal (as exposed or other) to the install place, and registers them. Again, this list excludes Match.o As a result, a client of the package compiles all right (so long as it does not import Match) but fails at the link stage, lacking symbols in Match. This seems like a bug in Cabal, because it allows you to build and install an unusable package. Possible solutions I can think of: - Cabal does its own dependency analysis and calls GHC one module at a time - GHC gets a flag which prevents it finding any module other than those listed on the command line (although it may still do dependency analysis to figure out which order to compile them in) - The .cabal file is no longer reqd to list non-exposed modules. Instead Cabal works out what the non-exposed modules are (perhaps by calling GHC -M or something similar). Simon | -Original Message- | From: Duncan Coutts [mailto:[EMAIL PROTECTED] | Sent: 24 June 2007 04:33 | To: Serge D. Mechveliani | Cc: glasgow-haskell-bugs@haskell.org; Simon Peyton-Jones | Subject: Re: skipping module in .cabal | | On Sat, 2007-06-23 at 12:08 +0400, Serge D. Mechveliani wrote: | Dear GHC developers, | | Recently I submitted a bug report #1452 for ghc-6.6.1 | of undefined references at the stage of linking executable, | and also of ignoring un-existing module import. | | Now I discovered the following strange effect | (see the report source modules) which, probably, explains much. | | 1. (minor note) The file Match.hs-boot is not needed. | All the effects preserve after its removal. | | 2. The name `Match' must be in the list `other-modules:' | in the file | dm.cabal,which describes the package. | | But it is not in dm.cabal ! | Because I have forgotten to put it there. | | Currently Cabal uses ghc --make to build packages. It starts from all | the modules listed in the exposed-modules but ghc --make will find any | other modules that are imported, even if they are not listed in | the .cabal file in the exposed-modules or other-modules fields. | | That's the current system. The right system I think is for Cabal to do | the dependency analysis itself (it needs to do that for proper support | of pre-processors anyway). That would allow Cabal to notice when | modules | are imported but not listed in either the exposed-modules or | other-modules fields. It could issue a warning or an error. | | Duncan ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1465: Type errors due to different package versions are a bit cryptic
#1465: Type errors due to different package versions are a bit cryptic +--- Reporter: guest|Owner: Type: bug | Status: new Priority: normal |Milestone: 6.8 Component: Compiler (Type checker) | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Os: Unknown | Testcase: Architecture: Unknown | +--- Changes (by simonmar): * milestone: = 6.8 * type: feature request = bug Comment: Yes, this is really a bug, so I'm marking it as such. We thought about it, and then promptly forgot about it, when we added support for multiple versions of packages, I don't think we want to ''always'' add the package name. What is a non- local type? One that comes from another package? Then `Int` is non- local too. My suggestion would be to add the package name if the types that fail to unify have the same qualified name. Perhaps add an option to include the package names unconditionally. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1465 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1074: -fwarn-unused-imports complains about wrong import
#1074: -fwarn-unused-imports complains about wrong import -+-- Reporter: guest |Owner: Type: bug | Status: new Priority: normal|Milestone: _|_ Component: Compiler | Version: 6.6 Severity: minor | Resolution: Keywords:| Difficulty: Unknown Os: MacOS X | Testcase: Architecture: powerpc | -+-- Comment (by simonpj): Thanks for further examples. The more examples we have, the more likely we are to get it right when we eventually fix this one! (It's trickier than one would think.) But as my comment above says, to fix it properly requires some real work, and since it's (by definition) not a show-stopper, it's not top of the priority list. (Unless you all say it is!) Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1074 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1463: Module → Package loo kup in ghc-pkg?
#1463: Module → Package lookup in ghc-pkg? --+- Reporter: [EMAIL PROTECTED] |Owner: Type: feature request| Status: new Priority: normal |Milestone: 6.10 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown| Testcase: Architecture: Unknown| --+- Comment (by claus): To get an InstalledPackageInfo for a given package, you have to use ghc- pkg describe and parse the output (I believe it should work). Parsing package.conf directly is non-portable, and risks breakage in the future. hmm. i was looking for a portable, cabal-based way to get the info. i wouldn't mind if cabal offered me a way to get that without telling me what the actual representation is, but InstalledPackageInfo seems to be the only concrete format defined so far, so converting whatever the actual format is into that would seem to make sense. if there is no cabal way (ghc-pkg certainly isn't), the next best thing would be to use the ghc api, provided that the ghc-pkg functionality is exposed there? alternatively, ghc-pkg itself could be extended, but i assume that different tools prefer the info in different formats, so i'd prefer a programmable solution, without reparsing unstable output formats. btw, 'ghc --simple-output field exposed-modules' should probably drop the field label? just to explain the dilemma: currently, my haskell mode for vim uses vimscript to extract part of the info from haddock's index files, and another part of the info from calling 'ghc -e :browse' on all imported modules. it then builds dictionaries for fast access to that info, and in the case of standard libs, caches that dictionary in a file for speed. now, haddock is the only tool that knows which identifiers in the installed libs have haddock comments, and what their relative urls are, but i can't help feeling that there must be an easier way to get all that info (i'm not even trying to extract types from haddock index files). i assume David has something similar in mind for emacs? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1463 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1452: undefined reference while linking executable (for cyclic import project) in ghc-6.6.1
#1452: undefined reference while linking executable (for cyclic import project) in ghc-6.6.1 --+- Reporter: guest |Owner: guest Type: bug| Status: assigned Priority: normal |Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: cyclic import | Difficulty: Moderate (1 day) Os: Linux | Testcase: Architecture: x86| --+- Comment (by simonpj): Just to make this 100% explicit: * Cabal uses ghc --make to build a bunch of .o files (including Match.o) * Cabal then links the .o files that are listed in dm.cabal (as exposed or other) to make a .a file. This list accidentally excludes Match.o * Cabal copies the .a file and the .hi files listed in dm.cabal (as exposed or other) to the install place, and registers them. Again, this list excludes Match.o As a result, a client of the package compiles all right (so long as it does not import Match) but fails at the link stage, lacking symbols in Match. This seems like a bug in Cabal, because it allows you to build and install an unusable package. Possible solutions I can think of: * Cabal does its own dependency analysis and calls GHC one module at a time * GHC gets a flag which prevents it finding any module other than those listed on the command line (although it may still do dependency analysis to figure out which order to compile them in) * The .cabal file is no longer reqd to list non-exposed modules. Instead Cabal works out what the non-exposed modules are (perhaps by calling GHC -M or something similar). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1452 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1453: addition to #1452 : it ignores import UnknownModule
#1453: addition to #1452 : it ignores import UnknownModule -+-- Reporter: [EMAIL PROTECTED] |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 6.6.1 Severity: normal| Resolution: Keywords: unknown module| Difficulty: Unknown Os: Linux | Testcase: ticket #1452 Architecture: x86 | -+-- Comment (by simonpj): This one at least is easy. Your little system dm/ simply does not use `Reduce.hs-boot`. It is not imported, it is not compiled... it's simply unused. So you could put anything in it that you like, and no error would be reported! The only hs-boot module that is SOURCE-imported is `Bool0`. So I declare this absent error message to be a non-error. I'll close this bug shortly unless you tell me I'm mistaken. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1453 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1437: Build failures on Mac OS X 10.5
#1437: Build failures on Mac OS X 10.5 --+- Reporter: [EMAIL PROTECTED] |Owner: Type: bug| Status: new Priority: normal |Milestone: 6.8 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: MacOS X| Testcase: Architecture: x86| --+- Comment (by [EMAIL PROTECTED]): I've forgotten, that compiling with `-O0` does not go via C, so `-keep-hc- files` must be given with `-fvia-C` (or did you find any *.hc sources that contained `sbqE_info`). The alternative would be to `-keep-s-file` and `-fasm`, but I rather look at C-code than at assembly. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1437 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
-keep-hc-files or -keep-hc-file?
I'm currently confused if it must be plural or singular (or any) http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#keeping-intermediates shows plural options whereas http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html#id3131928 shows them in singular (except -keep-tmp-files) Cheers Christian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1463: Module → Package loo kup in ghc-pkg?
#1463: Module → Package lookup in ghc-pkg? --+- Reporter: [EMAIL PROTECTED] |Owner: Type: feature request| Status: new Priority: normal |Milestone: 6.10 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown| Testcase: Architecture: Unknown| --+- Comment (by simonmar): hmm. i was looking for a portable, cabal-based way to get the info. i wouldn't mind if cabal offered me a way to get that without telling me what the actual representation is, but !InstalledPackageInfo seems to be the only concrete format defined so far, so converting whatever the actual format is into that would seem to make sense. Cabal doesn't currently have what you're asking for, but there's no reason it couldn't be added. It could be implemented exactly as I described: invoke `ghc-pkg describe` and parse the output. You would have to tell Cabal what command to use for `ghc-pkg`, or re-use some of Cabal's configuration machinery. In theory this method is portable; in practice only GHC has an `hc-pkg` command at the moment. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1463 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1437: Build failures on Mac OS X 10.5
#1437: Build failures on Mac OS X 10.5 --+- Reporter: [EMAIL PROTECTED] |Owner: Type: bug| Status: new Priority: normal |Milestone: 6.8 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: MacOS X| Testcase: Architecture: x86| --+- Comment (by [EMAIL PROTECTED]): `sbqE_info` also matches in the installed `ghc-6.6.1/lib/ghc-6.6.1/libHSbase.a`. So it may only get in via linking? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1437 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1437: Build failures on Mac OS X 10.5
#1437: Build failures on Mac OS X 10.5
--+-
Reporter: [EMAIL PROTECTED] |Owner:
Type: bug| Status: new
Priority: normal |Milestone: 6.8
Component: Compiler | Version: 6.6.1
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Os: MacOS X| Testcase:
Architecture: x86|
--+-
Comment (by [EMAIL PROTECTED]):
I've set `-keep-hc-files` under `GhcLibHcOpts +=` in `mk/build.mk` and
found:
{{{
libraries/base/GHC/Float.hc:static StgWord sbqE_info[] = {
libraries/base/GHC/Float.hc:II_(sbqE_info);
libraries/base/GHC/Float.hc:Sp[2] = (W_)sbqE_info;
}}}
I'm not sure if the name `sbqE_info` is created deterministically, though.
(I'll try to prepare hc-sources.)
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1437
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1437: Build failures on Mac OS X 10.5
#1437: Build failures on Mac OS X 10.5 --+- Reporter: [EMAIL PROTECTED] |Owner: Type: bug| Status: new Priority: normal |Milestone: 6.8 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: MacOS X| Testcase: Architecture: x86| --+- Comment (by guest): I've verified that the installed libHSbase.a contains code that looks like the code that is crashing. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1437 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1437: Build failures on Mac OS X 10.5
#1437: Build failures on Mac OS X 10.5
--+-
Reporter: [EMAIL PROTECTED] |Owner:
Type: bug| Status: new
Priority: normal |Milestone: 6.8
Component: Compiler | Version: 6.6.1
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Os: MacOS X| Testcase:
Architecture: x86|
--+-
Comment (by [EMAIL PROTECTED]):
As described under
http://hackage.haskell.org/trac/ghc/wiki/Building/Porting
I've created a `hc-file-bundle` at http://www.informatik.uni-
bremen.de/agbkb/forschung/formal_methods/CoFI/hets/intel-
mac/versions/ghc-6.6.1-i386-apple-darwin-hc.tar.gz
Making the bundle reported the following (hopefully unimportant) errors:
{{{
tar: ghc-6.6.1/rts/AutoApply_debug.hc: Cannot stat: No such file or
directory
tar: ghc-6.6.1/rts/AutoApply_thr.hc: Cannot stat: No such file or
directory
tar: ghc-6.6.1/rts/AutoApply_thr_debug.hc: Cannot stat: No such file or
directory
tar: ghc-6.6.1/rts/AutoApply_thr_p.hc: Cannot stat: No such file or
directory
tar: ghc-6.6.1/libraries/haskell-src/Language/Haskell/Parser.hs: Cannot
stat: No
such file or directory
}}}
Indeed I my files had names like `AutoApply_debug.debug_hc`,
`AutoApply_thr.thr_hc`, etc.
When trying to boot from these files I got the following error:
{{{
Apply.hc:104: warning: no previous prototype for 'stg_PAP_entry'
Apply.hc:152: warning: no previous prototype for 'stg_AP_entry'
Apply.hc:187: warning: no previous prototype for 'stg_AP_STACK_entry'
../driver/mangler/ghc-asm Apply.raw_s Apply.s
Darwin/x86: -fPIC -via-C doesn't work yet, use -fasm. Aborting. at
../driver/mangler/ghc-asm line 877, INASM line 268.
gmake: *** [Apply.s] Error 255
gmake: *** Deleting file `Apply.s'
rm Apply.raw_s
}}}
And I don't know how to continue
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1437
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1452: undefined reference while linking executable (for cyclic import project) in ghc-6.6.1
#1452: undefined reference while linking executable (for cyclic import project) in ghc-6.6.1 --+- Reporter: guest |Owner: guest Type: bug| Status: assigned Priority: normal |Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: cyclic import | Difficulty: Moderate (1 day) Os: Linux | Testcase: Architecture: x86| --+- Comment (by ross): Another possible solution: * Cabal currently puts preprocessor output in another directory, which it adds to the search path for ghc --make. If modules that don't require preprocessing were treated as having an identity preprocessor, and just copied into that directory (if they're listed in the .cabal file), then only that directory need be on the search path for ghc --make, and unlisted modules would generate compile errors. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1452 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1410: Control.Monad.Reader documentation
#1410: Control.Monad.Reader documentation --+- Reporter: guest |Owner: Type: proposal | Status: new Priority: normal |Milestone: Not GHC Component: libraries (other) | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Multiple | Testcase: Architecture: Multiple | --+- Comment (by guest): Ready to commit. There was no discussion on the patch exceot Ian Lynagh noticed wrong formatting. Fixed the formatting in the submitted patch. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1410 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
