Re: Cabal 1.22 RC ready to test
On Sat, Jan 3, 2015 at 2:36 AM, Mikhail Glushenkov the.dead.shall.r...@gmail.com wrote: Hi, On 3 January 2015 at 03:36, Johan Tibell johan.tib...@gmail.com wrote: If I don't hear anything the next few days I will make the release. The test suite doesn't compile with GHC HEAD on Travis. The error (https://travis-ci.org/haskell/cabal/jobs/45758614) is quite perplexing: [62 of 77] Compiling Distribution.Client.Config ( Distribution/Client/Config.hs, dist/dist-sandbox-8940a882/build/cabal/cabal-tmp/Distribution/Client/Config.o ) Distribution/Client/Config.hs:56:12: Module ‘Distribution.Simple.Compiler’ does not export ‘DebugInfoLevel(..)’ cabal: Error: some packages failed to install: cabal-install-1.22.0.0 failed during the building phase. The exception was: ExitFailure 1 Distribution.Simple.Compiler most definitely does export DebugInfoLevel, otherwise it wouldn't compile with the other GHC versions. Does GHC do something special with Cabal nowadays when it's no longer tied to GHC? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Shipping core libraries with debug symbols
How much debug info (as a percentage) do we currently generate? Could we just keep it in there in the release? On Sat, Jan 3, 2015 at 1:33 PM, Peter Wortmann sc...@leeds.ac.uk wrote: The debian package seems to simply put un-stripped libraries into a special path (/usr/lib/debug/...). This should be relatively straight-forward to implement. Note though that from a look at the RPM infrastructure, they have a tool in there (dwarfread) which actually parses through DWARF information and updates paths, so there is possibly more going on here. On the other hand, supporting -gsplit-dwarf seems to be a different mechanism, called Fission[1]. I haven't looked too much at the implementation yet, but to me it looks like it means generating copies of debug sections (such as .debug-line.dwo) which will then be extracted using objcopy --extract-dwo. This might take a bit more work to implement, both on DWARF generation code as well as infrastructure. Interestingly enough, doing this kind of splitting will actually buy us next to nothing - with Fission both .debug_line and .debug_frame would remain in the binary unchanged, so all we'd export would be some fairly inconsequential data from .debug_info. In contrast to other programming languages, we just don't have that much debug information in the first place. Well, at least not yet. Greetings, Peter [1] https://gcc.gnu.org/wiki/DebugFission On 03/01/2015 00:18, Johan Tibell wrote: 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Shipping core libraries with debug symbols
The debian package seems to simply put un-stripped libraries into a special path (/usr/lib/debug/...). This should be relatively straight-forward to implement. Note though that from a look at the RPM infrastructure, they have a tool in there (dwarfread) which actually parses through DWARF information and updates paths, so there is possibly more going on here. On the other hand, supporting -gsplit-dwarf seems to be a different mechanism, called Fission[1]. I haven't looked too much at the implementation yet, but to me it looks like it means generating copies of debug sections (such as .debug-line.dwo) which will then be extracted using objcopy --extract-dwo. This might take a bit more work to implement, both on DWARF generation code as well as infrastructure. Interestingly enough, doing this kind of splitting will actually buy us next to nothing - with Fission both .debug_line and .debug_frame would remain in the binary unchanged, so all we'd export would be some fairly inconsequential data from .debug_info. In contrast to other programming languages, we just don't have that much debug information in the first place. Well, at least not yet. Greetings, Peter [1] https://gcc.gnu.org/wiki/DebugFission On 03/01/2015 00:18, Johan Tibell wrote: 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Cabal 1.22 RC ready to test
I'm pretty sure we just need to update the submodule. On Sat, Jan 3, 2015 at 5:20 PM, Alan Kim Zimmerman alan.z...@gmail.com wrote: I tried to build https://github.com/ghc/packages-Cabal earlier today and got the same error, but it went fine with the version at https://github.com/haskell/cabal On Sat, Jan 3, 2015 at 10:17 PM, Johan Tibell johan.tib...@gmail.com wrote: It might be as simple as bumping the Cabal submodule in GHC to match the upstream 1.22 branch. On Sat, Jan 3, 2015 at 8:46 AM, Jake Wheat jakewheatm...@gmail.com wrote: On 3 January 2015 at 15:05, Johan Tibell johan.tib...@gmail.com wrote: The error (https://travis-ci.org/haskell/cabal/jobs/45758614) is quite perplexing: [62 of 77] Compiling Distribution.Client.Config ( Distribution/Client/Config.hs, dist/dist-sandbox-8940a882/build/cabal/cabal-tmp/Distribution/Client/Config.o ) Distribution/Client/Config.hs:56:12: Module ‘Distribution.Simple.Compiler’ does not export ‘DebugInfoLevel(..)’ cabal: Error: some packages failed to install: cabal-install-1.22.0.0 failed during the building phase. The exception was: ExitFailure 1 Distribution.Simple.Compiler most definitely does export DebugInfoLevel, otherwise it wouldn't compile with the other GHC versions. Does GHC do something special with Cabal nowadays when it's no longer tied to GHC? Is it because the Cabal-1.22.0.0 bundled with ghc is now different to the Cabal-1.22.0.0 in github? I get the same error compiling the master branch cabal-install with ghc-7.10.0-20141222. I think one solution is to increase the version number of Cabal in github (for 1.22 and master branches), and to make the latest cabal-install depend on this (i.e. Cabal=1.22.0.1) since cabal-install 1.22 in github no longer works with the 'released' snapshot Cabal-1.22.0.0 in ghc. This fixes the error for ghc-7.10.0-20141222. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows build gotchas
On Thu, Jan 1, 2015 at 6:42 PM, Herbert Valerio Riedel hvrie...@gmail.com wrote: I noticed that the cabal output made reference to C:\Users\Martin\AppData\Roaming\cabal\, so tried moving that out of the way, but it only made the problem worse. I did figure it out eventually: in addition to that directory, %APPDATA%\cabal, there were also files left over in %APPDATA%\ghc. Once I removed that directory as well, things started working again - but it took me a lot of time frustration to get there. That's btw because Cabal/GHC uses `getAppUserDataDirectory cabal` and `getAppUserDataDirectory ghc` respectively... Hrm. It seems the behaviour of getAppUserDataDirectory is decided at compile-time, by way of `#if defined(mingw32_HOST_OS)`: http://hackage.haskell.org/package/directory/docs/src/System-Directory.html#getAppUserDataDirectory So, given the build GHC on Windows procedure involves downloading Cabal as a binary, it could only be changed by using a different binary. And much as I might be able to argue it'd make sense for getAppUserDataDirectory to use $HOME instead of %APPDATA% when in MSYS, changing it would be a backwards-compatibility-breaking change to System.Directory. Well, I suppose, theoretically, it could do something like... use the value of some special environment variable if it's set at runtime, otherwise retain the existing behaviour. But that doesn't feel like it'd be good practice to me - too hacky. So I guess that'll be staying as it is, then. Good to know why it's like that, though - it makes a lot more sense now. Thanks for the pointer! - Martin ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Cabal 1.22 RC ready to test
I tried to build https://github.com/ghc/packages-Cabal earlier today and got the same error, but it went fine with the version at https://github.com/haskell/cabal On Sat, Jan 3, 2015 at 10:17 PM, Johan Tibell johan.tib...@gmail.com wrote: It might be as simple as bumping the Cabal submodule in GHC to match the upstream 1.22 branch. On Sat, Jan 3, 2015 at 8:46 AM, Jake Wheat jakewheatm...@gmail.com wrote: On 3 January 2015 at 15:05, Johan Tibell johan.tib...@gmail.com wrote: The error (https://travis-ci.org/haskell/cabal/jobs/45758614) is quite perplexing: [62 of 77] Compiling Distribution.Client.Config ( Distribution/Client/Config.hs, dist/dist-sandbox-8940a882/build/cabal/cabal-tmp/Distribution/Client/Config.o ) Distribution/Client/Config.hs:56:12: Module ‘Distribution.Simple.Compiler’ does not export ‘DebugInfoLevel(..)’ cabal: Error: some packages failed to install: cabal-install-1.22.0.0 failed during the building phase. The exception was: ExitFailure 1 Distribution.Simple.Compiler most definitely does export DebugInfoLevel, otherwise it wouldn't compile with the other GHC versions. Does GHC do something special with Cabal nowadays when it's no longer tied to GHC? Is it because the Cabal-1.22.0.0 bundled with ghc is now different to the Cabal-1.22.0.0 in github? I get the same error compiling the master branch cabal-install with ghc-7.10.0-20141222. I think one solution is to increase the version number of Cabal in github (for 1.22 and master branches), and to make the latest cabal-install depend on this (i.e. Cabal=1.22.0.1) since cabal-install 1.22 in github no longer works with the 'released' snapshot Cabal-1.22.0.0 in ghc. This fixes the error for ghc-7.10.0-20141222. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Cabal 1.22 RC ready to test
It might be as simple as bumping the Cabal submodule in GHC to match the upstream 1.22 branch. On Sat, Jan 3, 2015 at 8:46 AM, Jake Wheat jakewheatm...@gmail.com wrote: On 3 January 2015 at 15:05, Johan Tibell johan.tib...@gmail.com wrote: The error (https://travis-ci.org/haskell/cabal/jobs/45758614) is quite perplexing: [62 of 77] Compiling Distribution.Client.Config ( Distribution/Client/Config.hs, dist/dist-sandbox-8940a882/build/cabal/cabal-tmp/Distribution/Client/Config.o ) Distribution/Client/Config.hs:56:12: Module ‘Distribution.Simple.Compiler’ does not export ‘DebugInfoLevel(..)’ cabal: Error: some packages failed to install: cabal-install-1.22.0.0 failed during the building phase. The exception was: ExitFailure 1 Distribution.Simple.Compiler most definitely does export DebugInfoLevel, otherwise it wouldn't compile with the other GHC versions. Does GHC do something special with Cabal nowadays when it's no longer tied to GHC? Is it because the Cabal-1.22.0.0 bundled with ghc is now different to the Cabal-1.22.0.0 in github? I get the same error compiling the master branch cabal-install with ghc-7.10.0-20141222. I think one solution is to increase the version number of Cabal in github (for 1.22 and master branches), and to make the latest cabal-install depend on this (i.e. Cabal=1.22.0.1) since cabal-install 1.22 in github no longer works with the 'released' snapshot Cabal-1.22.0.0 in ghc. This fixes the error for ghc-7.10.0-20141222. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Bash completion in GHC 7.10
On Wed, 10 Dec 2014 16:43:57 +0400 Lennart Kolmodin kolmo...@gmail.com wrote: Hi everybody! TL;DL GHC 7.10 will have better bash completion, try it out! I'd like your help to verify the categorisation of DynFlags into ghc / ghci / shared or hidden flags. Thank you! On the way to users :) https://github.com/gentoo-haskell/gentoo-haskell/commit/d6f63341693063e60168bbddffb0806621696689 sf / # ghc --print-liTABENTER /usr/lib64/ghc-7.10.0.20141222 sf / # ghci --print-liTABENTER ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.20141222 for x86_64-unknown-linux): ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.20141222 for x86_64-unknown-linux): v_unsafeGlobalDynFlags: not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Absolutely not your fault, just makes such things more discoverable :] Thanks again! -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: cryptarithm2 +8.16%
Hi, Am Donnerstag, den 01.01.2015, 13:30 +0100 schrieb Joachim Breitner: due to #9938 ghcspeed did not measure every commit but somewhere in these commits, cryptarithm2 regressed by 8%: it seems that d8d003185a4bca1a1ebbadb518ef37bbc83a (When solving one Given from another, use the depth to control which way round) has solved this. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
linker error on OSX (symbol not found _iconv)
Hi, On OSX Yosemite I am facing the following build failure while building from the master (please find the complete error at the bottom of the email): ld: couldn't dlopen() /usr/lib/libdtrace.dylib: dlopen(/usr/lib/libdtrace.dylib, 1): Symbol not found: _iconv Referenced from: /usr/lib/libmecabra.dylib Expected in: /opt/local/lib/libiconv.2.dylib in /usr/lib/libmecabra.dylib for architecture x86_64 collect2: error: ld returned 1 exit status Can someone kindly point me what am doing wrong? FWIW, with the same configuration options, source distribution of ghc-7.8.4 from https://www.haskell.org/ghc/download_ghc_7_8_4 goes through successfully. I am using gcc (MacPorts gcc49 4.9.2_1) 4.9.2 Thanks, Hemanth The complete error message: ===--- building phase 0 /Library/Developer/CommandLineTools/usr/bin/make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 /Library/Developer/CommandLineTools/usr/bin/make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase /Library/Developer/CommandLineTools/usr/bin/make -r --no-print-directory -f ghc.mk phase=final all rm -f rts/dist/build/libHSrts-ghc7.11.20150103.dylib inplace/bin/ghc-stage1 -this-package-key rts -shared -dynamic -dynload deploy -no-auto-link-packages -Lrts/dist/build -lffi -optl-Wl,-rpath -optl-Wl,@loader_path `cat rts/dist/libs.depend` rts/dist/build/Adjustor.dyn_o rts/dist/build/Arena.dyn_o rts/dist/build/Capability.dyn_o rts/dist/build/CheckUnload.dyn_o rts/dist/build/ClosureFlags.dyn_o rts/dist/build/Disassembler.dyn_o rts/dist/build/FileLock.dyn_o rts/dist/build/Globals.dyn_o rts/dist/build/Hash.dyn_o rts/dist/build/Hpc.dyn_o rts/dist/build/HsFFI.dyn_o rts/dist/build/Inlines.dyn_o rts/dist/build/Interpreter.dyn_o rts/dist/build/LdvProfile.dyn_o rts/dist/build/Linker.dyn_o rts/dist/build/Messages.dyn_o rts/dist/build/OldARMAtomic.dyn_o rts/dist/build/Papi.dyn_o rts/dist/build/Printer.dyn_o rts/dist/build/ProfHeap.dyn_o rts/dist/build/Profiling.dyn_o rts/dist/build/Proftimer.dyn_o rts/dist/build/RaiseAsync.dyn_o rts/dist/build/RetainerProfile.dyn_o rts/dist/build/RetainerSet.dyn_o rts/dist/build/RtsAPI.dyn_o rts/dist/build/RtsDllMain.dyn_o rts/dist/build/RtsFlags.dyn_o rts/dist/build/RtsMain.dyn_o rts/dist/build/RtsMessages.dyn_o rts/dist/build/RtsStartup.dyn_o rts/dist/build/RtsUtils.dyn_o rts/dist/build/STM.dyn_o rts/dist/build/Schedule.dyn_o rts/dist/build/Sparks.dyn_o rts/dist/build/Stable.dyn_o rts/dist/build/StaticPtrTable.dyn_o rts/dist/build/Stats.dyn_o rts/dist/build/StgCRun.dyn_o rts/dist/build/StgPrimFloat.dyn_o rts/dist/build/Task.dyn_o rts/dist/build/ThreadLabels.dyn_o rts/dist/build/ThreadPaused.dyn_o rts/dist/build/Threads.dyn_o rts/dist/build/Ticky.dyn_o rts/dist/build/Timer.dyn_o rts/dist/build/Trace.dyn_o rts/dist/build/WSDeque.dyn_o rts/dist/build/Weak.dyn_o rts/dist/build/hooks/FlagDefaults.dyn_o rts/dist/build/hooks/MallocFail.dyn_o rts/dist/build/hooks/OnExit.dyn_o rts/dist/build/hooks/OutOfHeap.dyn_o rts/dist/build/hooks/StackOverflow.dyn_o rts/dist/build/sm/BlockAlloc.dyn_o rts/dist/build/sm/Compact.dyn_o rts/dist/build/sm/Evac.dyn_o rts/dist/build/sm/GC.dyn_o rts/dist/build/sm/GCAux.dyn_o rts/dist/build/sm/GCUtils.dyn_o rts/dist/build/sm/MBlock.dyn_o rts/dist/build/sm/MarkWeak.dyn_o rts/dist/build/sm/Sanity.dyn_o rts/dist/build/sm/Scav.dyn_o rts/dist/build/sm/Storage.dyn_o rts/dist/build/sm/Sweep.dyn_o rts/dist/build/eventlog/EventLog.dyn_o rts/dist/build/posix/GetEnv.dyn_o rts/dist/build/posix/GetTime.dyn_o rts/dist/build/posix/Itimer.dyn_o rts/dist/build/posix/OSMem.dyn_o rts/dist/build/posix/OSThreads.dyn_o rts/dist/build/posix/Select.dyn_o rts/dist/build/posix/Signals.dyn_o rts/dist/build/posix/TTY.dyn_o rts/dist/build/Apply.dyn_o rts/dist/build/Exception.dyn_o rts/dist/build/HeapStackCheck.dyn_o rts/dist/build/PrimOps.dyn_o rts/dist/build/StgMiscClosures.dyn_o rts/dist/build/StgStartup.dyn_o rts/dist/build/StgStdThunks.dyn_o rts/dist/build/Updates.dyn_o rts/dist/build/AutoApply.dyn_o -optl-m64 -fPIC -dynamic -H64m -O0 -fasm -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -dcmm-lint -DDTRACE -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2-fno-use-rpaths -o rts/dist/build/libHSrts-ghc7.11.20150103.dylib ld: couldn't dlopen() /usr/lib/libdtrace.dylib: dlopen(/usr/lib/libdtrace.dylib, 1): Symbol not found: _iconv Referenced from: /usr/lib/libmecabra.dylib Expected in: /opt/local/lib/libiconv.2.dylib in /usr/lib/libmecabra.dylib for architecture x86_64 collect2: error: ld returned 1 exit status make[1]: *** [rts/dist/build/libHSrts-ghc7.11.20150103.dylib] Error 1 make: *** [all] Error 2 ___ ghc-devs mailing list
