Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - feedback on Mac OS
Only problem remaining is compiling with -fllvm and running resulting executable Other problems below have now been solved: - cpphs - new version resolves problem - cabal install vector - upgrade to gcc (Homebrew gcc 4.9.2_1) 4.9.2 solves problem On Thu, Jan 1, 2015 at 9:58 AM, George Colpitts george.colpi...@gmail.com wrote: I built from source on Mac OS and found the following issues: - llvm , compiling with llvm (3.4.2) gives the following warnings: - $ ghc -fllvm cubeFast.hs [1 of 1] Compiling Main ( cubeFast.hs, cubeFast.o ) clang: warning: argument unused during compilation: '-fno-stack-protector' clang: warning: argument unused during compilation: '-D TABLES_NEXT_TO_CODE' clang: warning: argument unused during compilation: '-I .' clang: warning: argument unused during compilation: '-fno-common' clang: warning: argument unused during compilation: '-U __PIC__' clang: warning: argument unused during compilation: '-D __PIC__' Linking cubeFast ... - running the resulting executable crashes (compiling without -fllvm gives no warnings and executable works properly) - cat bigCube.txt | ./cubeFast /dev/null Segmentation fault: 11 - Exception Type:EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0xfffd5bfd8460 - cabal install vector fails: - [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic ( Data/Vector/Fusion/Stream/Monadic.hs, dist/build/Data/Vector/Fusion/Stream/Monadic.o ) command line: can't load .so/.DLL for: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib (dlopen(/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib, 5): no suitable image found. Did find: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib: mach-o, but wrong filetype) - cabal install cpphs fails: -cabal install cpphs Resolving dependencies... Configuring cpphs-1.13... Building cpphs-1.13... Failed to install cpphs-1.13 Build log ( /Users/gcolpitts/.cabal/logs/cpphs-1.13.log ): Warning: cpphs.cabal: Unknown fields: build-depends (line 5) Fields allowed in this section: name, version, cabal-version, build-type, license, license-file, license-files, copyright, maintainer, stability, homepage, package-url, bug-reports, synopsis, description, category, author, tested-with, data-files, data-dir, extra-source-files, extra-tmp-files, extra-doc-files Configuring cpphs-1.13... Building cpphs-1.13... Preprocessing library cpphs-1.13... - Language/Preprocessor/Cpphs.hs:1:1: Could not find module ‘Prelude’ It is a member of the hidden package ‘base-4.8.0.0’. Perhaps you need to add ‘base’ to the build-depends in your .cabal file. Use -v to see a list of the files searched for. Language/Preprocessor/Cpphs/CppIfdef.hs:32:8: Could not find module ‘Numeric’ It is a member of the hidden package ‘base-4.8.0.0’. Perhaps you need to add ‘base’ to the build-depends in your .cabal file. Use -v to see a list of the files searched for. Language/Preprocessor/Cpphs/CppIfdef.hs:33:8: Could not find module ‘System.IO.Unsafe’ It is a member of the hidden package ‘base-4.8.0.0’. Perhaps you need to add ‘base’ to the build-depends in your .cabal file. Use -v to see a list of the files searched for. Language/Preprocessor/Cpphs/CppIfdef.hs:34:8: Could not find module ‘System.IO’ It is a member of the hidden package ‘base-4.8.0.0’. Perhaps you need to add ‘base’ to the build-depends in your .cabal file. Use -v to see a list of the files searched for. Language/Preprocessor/Cpphs/MacroPass.hs:29:8: Could not find module ‘Control.Monad’ It is a member of the hidden package ‘base-4.8.0.0’. Perhaps you need to add ‘base’ to the build-depends in your .cabal file. Use -v to see a list of the files searched for. Language/Preprocessor/Cpphs/MacroPass.hs:30:8: Could not find module ‘System.Time’ Perhaps you meant System.CPUTime (needs flag -package-key base-4.8.0.0) System.Cmd (needs flag -package-key process-1.2.1.0@proce_ADbmNMhxdsoDn9NrOWjezu) System.Mem (needs flag -package-key base-4.8.0.0) Use -v to see a list of the files searched for. Language/Preprocessor/Cpphs/MacroPass.hs:31:8:
Re: Compiling nofib-analyse
Attached is a patch which axes HTML support in nofib-analyse. I would Phab it but I don't know how to do that for submodules. Maybe we should drop the LaTeX support too! Edward Excerpts from Edward Z. Yang's message of 2014-12-30 19:10:56 -0500: Pretty sure it's the aptly named 'html'. https://hackage.haskell.org/package/html I can't remember the last time I used the HTML reporting capability, so I'd be happy about removing it. Edward Excerpts from Simon Peyton Jones's message of 2014-12-30 07:03:17 -0500: When building nofib-analyse (in nofib), I get /home/simonpj/local/bin/ghc -O -cpp --make Main -o nofib-analyse Main.hs:14:18: Could not find module 'Text.Html' Use -v to see a list of the files searched for. There are rather a lot of HTML packages. Which one is needed? Does this meant that it's essential to install this package before running nofib, a manual step? I wonder if it'd be better to remove the HTML dependency, or make it optional? Simon 0001-Remove-HTML-generation-from-nofib-analyse-dropping-h.patch Description: Binary data ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Shipping core libraries with debug symbols
Brandon, If we just built GHC with debug symbols enabled, everything should just work from a packaging perspective? On Fri, Jan 2, 2015 at 7:26 PM, Brandon Allbery allber...@gmail.com wrote: On Fri, Jan 2, 2015 at 6:18 PM, Johan Tibell johan.tib...@gmail.com wrote: I believe other compilers, e.g. GCC, ship debug symbols in separate files (https://packages.debian.org/sid/libc-dbg ) that e.g. GDB can then look up. Lookaside debugging information is (a) a Linux-ism, although possibly also included in mingw --- but not OS X or the *BSDs (b) on RPM-based systems at least, is split out of objects into separate files, and thence into debug packages, by the standard RPM support macros before the standard strip step (I expect debuild does something similar on Debian-ish systems). -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Shipping core libraries with debug symbols
On Fri, Jan 2, 2015 at 6:18 PM, Johan Tibell johan.tib...@gmail.com wrote: I believe other compilers, e.g. GCC, ship debug symbols in separate files ( https://packages.debian.org/sid/libc-dbg ) that e.g. GDB can then look up. Lookaside debugging information is (a) a Linux-ism, although possibly also included in mingw --- but not OS X or the *BSDs (b) on RPM-based systems at least, is split out of objects into separate files, and thence into debug packages, by the standard RPM support macros before the standard strip step (I expect debuild does something similar on Debian-ish systems). -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Shipping core libraries with debug symbols
Hi! We are now able to generate DWARF debug info, by passing -g to GHC. This will allow for better debugging (e.g. using GDB) and profiling (e.g. using Linux perf events). To make this feature more user accessible we need to ship debug info for the core libraries (and perhaps the RTS). The reason we need to ship debug info is that it's difficult, or impossible in the case of base, for the user to rebuild these libraries.The question is, how do we do this well? I don't think our way solution works very well. It causes us to recompile too much and GHC doesn't know which ways have been built or not. I believe other compilers, e.g. GCC, ship debug symbols in separate files ( https://packages.debian.org/sid/libc-dbg) that e.g. GDB can then look up. -- Johan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Shipping core libraries with debug symbols
On Fri, Jan 2, 2015 at 7:54 PM, Johan Tibell johan.tib...@gmail.com wrote: If we just built GHC with debug symbols enabled, everything should just work from a packaging perspective? On most RPM systems, at least (I get debuginfo packages for local RPM builds, with nothing special in the specs files). Someone else would have to comment on Debian's build system, although I expect that it is similarly automated. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
