August 2015 - ghc-tickets

[GHC] #10779: .so files in 64-bit Debian builds are 4% larger than they have to be
by GHC 05 Sep '15

05 Sep '15

#10779: .so files in 64-bit Debian builds are 4% larger than they have to be -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build | Version: 7.10.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- For some reason, all .so files from the Debian builds at https://www.haskell.org/ghc/download_ghc_7_10_2#x86_64linux are larger then the equivalent files in the CentOS build, my own (Ubuntu) build, or hvr's ppa build. For example, comparing the size of `libHSfilepath-1.4.0.0 -KsGE6pHE5eZHSN90ZVax6A-ghc7.10.2.so`, after installation (i.e. after strip --strip-unneeded): ||= build =||= size (bytes) =|| || Debian || 128520 || || Centos || 124280 || || hvr ppa || 123112 || || my own || 123112 || Maybe the linker or strip utility on the Debian system where GHC releases are built should be upgraded. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10779> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10799: "I found a duplicate definition for symbol: __x86.get_pc_thunk.bx" in package network
by GHC 05 Sep '15

05 Sep '15

#10799: "I found a duplicate definition for symbol: __x86.get_pc_thunk.bx" in package network -------------------------------------+------------------------------------- Reporter: blueonyx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #9657 Differential Revisions: | -------------------------------------+------------------------------------- hi, i get this panic! using hint to interpret code which uses the network package (on 32bit ubuntu): {{{ GHC runtime linker: fatal error: I found a duplicate definition for symbol __i686.get_pc_thunk.bx whilst processing object file /home/mechgen/get_pc_thunk.bx/.cabal-sandbox/lib/i386-linux- ghc-7.10.2/network-2.6.2.1-F6mK9sCIw3M5SbZMt2lUQE/libHSnetwork-2.6.2.1-F6mK9sCIw3M5SbZMt2lUQE.a This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. Left (GhcException "panic! (the 'impossible' happened)\n (GHC version 7.10.2 for i386-unknown-linux):\n\tloadArchive \"/home/mechgen/get_pc_thunk.bx/.cabal-sandbox/lib/i386-linux- ghc-7.10.2/network-2.6.2.1-F6mK9sCIw3M5SbZMt2lUQE/libHSnetwork-2.6.2.1-F6mK9sCIw3M5SbZMt2lUQE.a\": failed\n\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\n") }}} the problem also arises when the interpreted module imports a module which imports network, so it doesn't have to import network directly. also "it worked before". i can't really remember the previous working versions, but it must have been something like ghc 7.6.3 and haskell- platform 2013.2.0.0. the related ticket mentioned building without -fPIC, but i can't find it in network's cabal file. more info: {{{ $ uname -a Linux mechgen 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:15:33 UTC 2013 i686 i686 i386 GNU/Linux $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.2 $ cabal --version cabal-install version 1.22.6.0 using version 1.22.4.0 of the Cabal library }}} to reproduce: {{{ $ mv ~/Compile.hs ~/DummyImportingNetwork.hs . $ cabal sandbox init $ cabal install network==2.6.2.1 hint==0.4.2.3 $ cabal exec -- ghc --make -o compile Compile.hs $ PATH=.:$PATH cabal exec compile }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10799> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9481: Linker does not correctly resolve symbols in previously loaded objects
by GHC 05 Sep '15

05 Sep '15

#9481: Linker does not correctly resolve symbols in previously loaded objects -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- '''Summary''': Given two object files (created from C files) A and B, where B refers to symbols defined in A, if we load B before A, calling `resolveObjs` after each object file, symbol resolution goes wrong. Full test case attached. '''Detailed description''': Consider {{{#!c // a.c #include <stdio.h> void defined_in_A() { printf("In A\n"); } }}} {{{#!c // b.c #include <stdio.h> void defined_in_A(); void defined_in_B() { printf("In B\n"); defined_in_A(); printf("In B\n"); } }}} and {{{#!hs {-# LANGUAGE ForeignFunctionInterface #-} module Main where import System.IO foreign import ccall "defined_in_B" defined_in_B :: IO () main :: IO () main = defined_in_B }}} and we use the GHC API to load the object files `a.o` and `b.o` (corresponding to `a.c` and `b.c`), calling `resolveObjs` after loading each object, and then load `Main` and call `Main.main`, everything works fine (the attached test case contains both `a.c`, `b.c` and `Main.hs` as well as the test program that calls into the GHC API). However, if we load `b.o` ''before'' `a.o`, things go wrong. When we load `b.o` and call `resolveObjs` then `resolveObjs` (quite reasonably) complains that {{{ lookupSymbol failed in relocateSection (relocate external) b.o: unknown symbol `_defined_in_A' }}} since we haven't loaded `a.o` yet. But when we then load `a.o` and call `resolveObjs` again, `resolveObjs` reports okay, but something goes wrong because the program subsequently segfaults. '''A successful run''' I took a closer look at what happens exactly. First, let's consider the test run where we load A before B, and everything works fine, and let's look at the precise code that we actually execute when `Main.main` does the foreign call to `defined_in_B`: {{{ # lldb Linkerbug Current executable set to 'Linkerbug' (x86_64). (lldb) breakpoint set -n ffi_call Breakpoint 1: where = Linkerbug`ffi_call + 29 at ffi64.c:421, address = 0x0000000102be2eed (lldb) run Process 92361 launched: 'Linkerbug' (x86_64) Loading object "a.o" symbol resolution ok Loading object "b.o" symbol resolution ok Loading Haskell module "Main.hs" ok Running "Main.main" Process 92361 stopped * thread #1: tid = 0x32048b, 0x0000000102be2eed Linkerbug`ffi_call(cif=0x000000010cc68500, fn=0x0000000104c6c210, rvalue=0x00007fff5fbff920, avalue=0x00007fff5fbff8c0) + 29 at ffi64.c:421, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0: 0x0000000102be2eed Linkerbug`ffi_call(cif=0x000000010cc68500, fn=0x0000000104c6c210, rvalue=0x00007fff5fbff920, avalue=0x00007fff5fbff8c0) + 29 at ffi64.c:421 (lldb) disassemble -c 14 -s fn 0x104c6c210: pushq %rbp 0x104c6c211: movq %rsp, %rbp 0x104c6c214: pushq %rbx 0x104c6c215: pushq %rax 0x104c6c216: leaq 0x1d(%rip), %rbx 0x104c6c21d: movq %rbx, %rdi 0x104c6c220: callq 0x104c6c3c8 0x104c6c225: xorl %eax, %eax 0x104c6c227: callq 0x104c6b210 0x104c6c22c: movq %rbx, %rdi 0x104c6c22f: addq $0x8, %rsp 0x104c6c233: popq %rbx 0x104c6c234: popq %rbp 0x104c6c235: jmpq 0x104c6c3c8 }}} This disassembly is the compiled code for B which, in order, does a call to `printf`, then to `defined_in_A`, and then back to `printf` (the last call is `jmpq` rather than `callq`: the C compiler did a tail call optimization). Let's make sure that this is actually true; the first call is a call to {{{ (lldb) disassemble -c 2 -s 0x104c6c3c8 0x104c6c3c8: jmpq *-0xe(%rip) 0x104c6c3ce: addb %al, (%rax) }}} which is an indirect jump to {{{ (lldb) memory read -f A -c 1 "0x104c6c3ce - 0xe" 0x104c6c3c0: 0x00007fff84fd5b9b libsystem_c.dylib`puts }}} to `puts`, okay, good. Seems an unnecessary level of indirection, but that's okay. The next call is to {{{ (lldb) disassemble -c 5 -s 0x104c6b210 0x104c6b210: pushq %rbp 0x104c6b211: movq %rsp, %rbp 0x104c6b214: leaq 0x6(%rip), %rdi 0x104c6b21b: popq %rbp 0x104c6b21c: jmpq 0x104c6b370 }}} which is the compiled code for `defined_in_A`, which should be just a call to `printf`. Let's confirm: {{{ (lldb) disassemble -c 2 -s 0x104c6b370 0x104c6b370: jmpq *-0xe(%rip) 0x104c6b376: addb %al, (%rax) (lldb) memory read -f A -c 1 "0x104c6b376 - 0xe" 0x104c6b368: 0x00007fff84fd5b9b libsystem_c.dylib`puts }}} Ok, all good. '''A failed run''' Now let's check what happens when we load the objects in the opposite order. The code that we execute is {{{ (lldb) disassemble -c 14 -s fn 0x104c6b210: pushq %rbp 0x104c6b211: movq %rsp, %rbp 0x104c6b214: pushq %rbx 0x104c6b215: pushq %rax 0x104c6b216: leaq 0x1d(%rip), %rbx 0x104c6b21d: movq %rbx, %rdi 0x104c6b220: callq 0x104c6b3c8 0x104c6b225: xorl %eax, %eax 0x104c6b227: callq 0x104c6c210 0x104c6b22c: movq %rbx, %rdi 0x104c6b22f: addq $0x8, %rsp 0x104c6b233: popq %rbx 0x104c6b234: popq %rbp 0x104c6b235: jmpq 0x104c6b556 }}} This immediately looks suspicious: the address of the `jmpq` (the second -- tail -- call to `printf`) is different from the first. The first `callq` is okay: {{{ (lldb) disassemble -c 2 -s 0x104c6b3c8 0x104c6b3c8: jmpq *-0xe(%rip) 0x104c6b3ce: addb %al, (%rax) (lldb) memory read -f A -c 1 "0x104c6b3ce - 0xe" 0x104c6b3c0: 0x00007fff84fd5b9b libsystem_c.dylib`puts }}} and the call to `defined_in_A`, as well as the code ''for'' `defined_in_A`, are both ok: {{{ (lldb) disassemble -c 5 -s 0x104c6c210 0x104c6c210: pushq %rbp 0x104c6c211: movq %rsp, %rbp 0x104c6c214: leaq 0x6(%rip), %rdi 0x104c6c21b: popq %rbp 0x104c6c21c: jmpq 0x104c6c370 (lldb) disassemble -c 2 -s 0x104c6c370 0x104c6c370: jmpq *-0xe(%rip) 0x104c6c376: addb %al, (%rax) (lldb) memory read -f A -c 1 "0x104c6c376 - 0xe" 0x104c6c368: 0x00007fff84fd5b9b libsystem_c.dylib`puts }}} However, that second call to `printf` (the `jmpq`) in `defined_in_B` is indeed wrong: it's jumping into nowhere: {{{ (lldb) memory read -c 8 0x104c6b556 0x104c6b556: 00 00 00 00 00 00 00 00 ........ }}} Note that somewhat surprisingly is it ''not'' the resolution of the symbol from `a.o` that is wrong; that ''does'' get resolved okay once we load `a.o`; rather, it is the jump to `puts` which is wrong (and then only the one of them). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9481> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9280: GHCi crash:
by GHC 05 Sep '15

05 Sep '15

#9280: GHCi crash: ------------------------------------------+-------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Keywords: crash, dynamic linking | Operating System: Architecture: x86_64 (amd64) | Unknown/Multiple Difficulty: Unknown | Type of failure: GHCi crash Blocked By: | Test Case: Related Tickets: | Blocking: ------------------------------------------+-------------------------------- Given a statically-linked Haskell object file, interactive GHCi 7.8.2 crashes. {{{ $ cat >Foo.hs <<EOF module Foo where foo :: IO () foo = print "Foo" EOF }}} On OS X: {{{ $ ghc -Wall -c -o Foo.o Foo.hs }}} {{{ $ ghci -v Foo.o GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Glasgow Haskell Compiler, Version 7.8.2, stage 2 booted by GHC version 7.6.3 Using binary package database: /opt/ghc-7.8.2/lib/ghc-7.8.2/package.conf.d/package.cache wired-in package ghc-prim mapped to ghc- prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8 wired-in package integer-gmp mapped to integer- gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99 wired-in package base mapped to base-4.7.0.0-a333addb6892f3cc2e6baa5ec782bd04 wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.9.0.0-ed6ecfb467e6936688bb20f968f702e1 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. *** gcc: /usr/bin/gcc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/opt/ghc-7.8.2/lib/ghc-7.8.2/base-4.7.0.0 --print-file-name libiconv.dylib Loading package base ... linking ... done. Loading object (static) Foo.o ... Created temporary directory: /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc41409_0 *** Linker: /usr/bin/gcc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -m64 -dynamiclib -o /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc41409_0/ghc41409_1.dylib Foo.o -undefined dynamic_lookup -single_module -install_name '@rpath/ghc41409_1.dylib' -L/opt/ghc-7.8.2/lib/ghc-7.8.2/base-4.7.0.0 -Wl,-rpath -Wl,/opt/ghc-7.8.2/lib/ghc-7.8.2/base-4.7.0.0 -L/opt/ghc-7.8.2/lib/ghc-7.8.2/integer-gmp-0.5.1.0 -Wl,-rpath -Wl,/opt/ghc-7.8.2/lib/ghc-7.8.2/integer-gmp-0.5.1.0 -L/opt/ghc-7.8.2/lib/ghc-7.8.2/ghc-prim-0.3.1.0 -Wl,-rpath -Wl,/opt/ghc-7.8.2/lib/ghc-7.8.2/ghc-prim-0.3.1.0 -L/opt/ghc-7.8.2/lib/ghc-7.8.2/rts-1.0 -Wl,-rpath -Wl,/opt/ghc-7.8.2/lib/ghc-7.8.2/rts-1.0 -lHSbase-4.7.0.0-ghc7.8.2 -lHSinteger-gmp-0.5.1.0-ghc7.8.2 -lHSghc-prim-0.3.1.0-ghc7.8.2 -liconv ld: illegal text-relocation to '_ghczmprim_GHCziCString_unpackCStringzh_closure' in /opt/ghc-7.8.2/lib/ghc-7.8.2/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.8.2.dylib from '_sVK_info' in Foo.o for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) *** Deleting temp files: Deleting: /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc41409_0/ghc41409_1.dylib Warning: deleting non-existent /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc41409_0/ghc41409_1.dylib *** Deleting temp dirs: Deleting: /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc41409_0 }}} On Linux, without `-fPIC`: {{{ $ ghc -Wall -c -o Foo.o Foo.hs }}} {{{ ghci -v Foo.o GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Glasgow Haskell Compiler, Version 7.8.2, stage 2 booted by GHC version 7.6.3 Using binary package database: /app/.halcyon/ghc/lib/ghc-7.8.2/package.conf.d/package.cache wired-in package ghc-prim mapped to ghc- prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8 wired-in package integer-gmp mapped to integer- gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99 wired-in package base mapped to base-4.7.0.0-018311399e3b6350d5be3a16b144df9b wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.9.0.0-dcc8c210fb02937e104bc1784d7b0f06 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: Loading package ghc-prim ... linking ... done. *** gcc: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/app/.halcyon/ghc/lib/ghc-7.8.2/integer-gmp-0.5.1.0 --print-file-name libgmp.so Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static) Foo.o ... Created temporary directory: /tmp/ghc7203_0 *** Linker: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -o /tmp/ghc7203_0/ghc7203_1.so Foo.o -shared -Wl,-Bsymbolic -Wl,-h,ghc7203_1.so -L/app/.halcyon/ghc/lib/ghc-7.8.2/base-4.7.0.0 -Wl,-rpath -Wl,/app/.halcyon/ghc/lib/ghc-7.8.2/base-4.7.0.0 -L/app/.halcyon/ghc/lib/ghc-7.8.2/integer-gmp-0.5.1.0 -Wl,-rpath -Wl,/app/.halcyon/ghc/lib/ghc-7.8.2/integer-gmp-0.5.1.0 -L/app/.halcyon/ghc/lib/ghc-7.8.2/ghc-prim-0.3.1.0 -Wl,-rpath -Wl,/app/.halcyon/ghc/lib/ghc-7.8.2/ghc-prim-0.3.1.0 -L/app/.halcyon/ghc/lib/ghc-7.8.2/rts-1.0 -Wl,-rpath -Wl,/app/.halcyon/ghc/lib/ghc-7.8.2/rts-1.0 -lHSbase-4.7.0.0-ghc7.8.2 -lHSinteger-gmp-0.5.1.0-ghc7.8.2 -lHSghc-prim-0.3.1.0-ghc7.8.2 -lgmp '-Wl ,--hash-size=31' -Wl,--reduce-memory-overheads /usr/bin/ld: Foo.o: relocation R_X86_64_32S against `stg_bh_upd_frame_info' can not be used when making a shared object; recompile with -fPIC Foo.o: could not read symbols: Bad value collect2: ld returned 1 exit status *** Deleting temp files: Deleting: /tmp/ghc7203_0/ghc7203_1.so Warning: deleting non-existent /tmp/ghc7203_0/ghc7203_1.so *** Deleting temp dirs: Deleting: /tmp/ghc7203_0 }}} On Linux, with `-fPIC`: {{{ $ ghc -Wall -c -fPIC -o Foo.o Foo.hs }}} {{{ $ ghci -v Foo.o GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Glasgow Haskell Compiler, Version 7.8.2, stage 2 booted by GHC version 7.6.3 Using binary package database: /app/.halcyon/ghc/lib/ghc-7.8.2/package.conf.d/package.cache wired-in package ghc-prim mapped to ghc- prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8 wired-in package integer-gmp mapped to integer- gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99 wired-in package base mapped to base-4.7.0.0-018311399e3b6350d5be3a16b144df9b wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.9.0.0-dcc8c210fb02937e104bc1784d7b0f06 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: Loading package ghc-prim ... linking ... done. *** gcc: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/app/.halcyon/ghc/lib/ghc-7.8.2/integer-gmp-0.5.1.0 --print-file-name libgmp.so Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static) Foo.o ... Created temporary directory: /tmp/ghc7223_0 *** Linker: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -o /tmp/ghc7223_0/ghc7223_1.so Foo.o -shared -Wl,-Bsymbolic -Wl,-h,ghc7223_1.so -L/app/.halcyon/ghc/lib/ghc-7.8.2/base-4.7.0.0 -Wl,-rpath -Wl,/app/.halcyon/ghc/lib/ghc-7.8.2/base-4.7.0.0 -L/app/.halcyon/ghc/lib/ghc-7.8.2/integer-gmp-0.5.1.0 -Wl,-rpath -Wl,/app/.halcyon/ghc/lib/ghc-7.8.2/integer-gmp-0.5.1.0 -L/app/.halcyon/ghc/lib/ghc-7.8.2/ghc-prim-0.3.1.0 -Wl,-rpath -Wl,/app/.halcyon/ghc/lib/ghc-7.8.2/ghc-prim-0.3.1.0 -L/app/.halcyon/ghc/lib/ghc-7.8.2/rts-1.0 -Wl,-rpath -Wl,/app/.halcyon/ghc/lib/ghc-7.8.2/rts-1.0 -lHSbase-4.7.0.0-ghc7.8.2 -lHSinteger-gmp-0.5.1.0-ghc7.8.2 -lHSghc-prim-0.3.1.0-ghc7.8.2 -lgmp '-Wl ,--hash-size=31' -Wl,--reduce-memory-overheads /usr/bin/ld: Foo.o: relocation R_X86_64_PC32 against undefined symbol `ghczmprim_GHCziCString_unpackCStringzh_closure' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status *** Deleting temp files: Deleting: /tmp/ghc7223_0/ghc7223_1.so Warning: deleting non-existent /tmp/ghc7223_0/ghc7223_1.so *** Deleting temp dirs: Deleting: /tmp/ghc7223_0 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9280> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8229: Linking in Windows is slow
by GHC 05 Sep '15

05 Sep '15

#8229: Linking in Windows is slow -------------------------+------------------------------------------------- Reporter: | Owner: ezyang | Status: new Type: bug | Milestone: 7.8.1 Priority: | Version: 7.7 normal | Operating System: Windows Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- It takes a long time to link ghc-stage2 on Windows; several minutes on what should be a pretty beefy machine. Here is the linker command: {{{ "C:\Users\ezyang\Dev\ghc-validate\inplace\lib/../mingw/bin/gcc.exe" "-U__i686" "-fno-stack-prot ector" "-DTABLES_NEXT_TO_CODE" "-o" "compiler/stage2/build/libHSghc-7.7.20130904-ghc7.7.2013090 4.dll" "-shared" "-Wl,--out- implib=compiler/stage2/build/libHSghc-7.7.20130904-ghc7.7.20130904. dll.a" "-Wl,--enable-auto-import" "compiler\stage2\build\GhcMonad.dyn_o" "compiler\stage2\build \Llvm.dyn_o" "compiler\stage2\build\Llvm\AbsSyn.dyn_o" "compiler\stage2\build\Llvm\MetaData.dyn _o" "compiler\stage2\build\Llvm\PpLlvm.dyn_o" "compiler\stage2\build\Llvm\Types.dyn_o" "compile r\stage2\build\LlvmCodeGen.dyn_o" "compiler\stage2\build\LlvmCodeGen\Base.dyn_o" "compiler\stag e2\build\LlvmCodeGen\CodeGen.dyn_o" "compiler\stage2\build\LlvmCodeGen\Data.dyn_o" "compiler\st age2\build\LlvmCodeGen\Ppr.dyn_o" "compiler\stage2\build\LlvmCodeGen\Regs.dyn_o" "compiler\stag e2\build\LlvmMangler.dyn_o" "compiler\stage2\build\CmmBuildInfoTables.dyn_o" "compiler\stage2\b uild\CmmPipeline.dyn_o" "compiler\stage2\build\CmmCommonBlockElim.dyn_o" "compiler\stage2\build \CmmContFlowOpt.dyn_o" "compiler\stage2\build\CmmLex.dyn_o" "compiler\stage2\build\CmmLint.dyn_ o" "compiler\stage2\build\CmmLive.dyn_o" "compiler\stage2\build\CmmOpt.dyn_o" "compiler\stage2\ build\CmmParse.dyn_o" "compiler\stage2\build\CmmProcPoint.dyn_o" "compiler\stage2\build\CmmRewr iteAssignments.dyn_o" "compiler\stage2\build\CmmSink.dyn_o" "compiler\stage2\build\CmmLayoutSta ck.dyn_o" "compiler\stage2\build\PprBase.dyn_o" "compiler\stage2\build\PprC.dyn_o" "compiler\st age2\build\CgUtils.dyn_o" "compiler\stage2\build\StgCmm.dyn_o" "compiler\stage2\build\StgCmmBin d.dyn_o" "compiler\stage2\build\StgCmmCon.dyn_o" "compiler\stage2\build\StgCmmExpr.dyn_o" "comp iler\stage2\build\StgCmmForeign.dyn_o" "compiler\stage2\build\StgCmmHeap.dyn_o" "compiler\stage 2\build\StgCmmHpc.dyn_o" "compiler\stage2\build\StgCmmPrim.dyn_o" "compiler\stage2\build\StgCmm ExtCode.dyn_o" "compiler\stage2\build\CoreLint.dyn_o" "compiler\stage2\build\CorePrep.dyn_o" "c ompiler\stage2\build\ExternalCore.dyn_o" "compiler\stage2\build\MkExternalCore.dyn_o" "compiler \stage2\build\PprExternalCore.dyn_o" "compiler\stage2\build\Check.dyn_o" "compiler\stage2\build \Coverage.dyn_o" "compiler\stage2\build\Desugar.dyn_o" "compiler\stage2\build\DsArrows.dyn_o" " compiler\stage2\build\DsBinds.dyn_o" "compiler\stage2\build\DsCCall.dyn_o" "compiler\stage2\bui ld\DsExpr.dyn_o" "compiler\stage2\build\DsForeign.dyn_o" "compiler\stage2\build\DsGRHSs.dyn_o" "compiler\stage2\build\DsListComp.dyn_o" "compiler\stage2\build\DsMonad.dyn_o" "compiler\stage2 \build\DsUtils.dyn_o" "compiler\stage2\build\Match.dyn_o" "compiler\stage2\build\MatchCon.dyn_o " "compiler\stage2\build\MatchLit.dyn_o" "compiler\stage2\build\BinIface.dyn_o" "compiler\stage 2\build\BuildTyCl.dyn_o" "compiler\stage2\build\IfaceEnv.dyn_o" "compiler\stage2\build\LoadIfac e.dyn_o" "compiler\stage2\build\MkIface.dyn_o" "compiler\stage2\build\TcIface.dyn_o" "compiler\ stage2\build\FlagChecker.dyn_o" "compiler\stage2\build\CodeOutput.dyn_o" "compiler\stage2\build \DriverMkDepend.dyn_o" "compiler\stage2\build\DriverPipeline.dyn_o" "compiler\stage2\build\Find er.dyn_o" "compiler\stage2\build\GHC.dyn_o" "compiler\stage2\build\GhcMake.dyn_o" "compiler\sta ge2\build\GhcPlugins.dyn_o" "compiler\stage2\build\DynamicLoading.dyn_o" "compiler\stage2\build \HeaderInfo.dyn_o" "compiler\stage2\build\HscMain.dyn_o" "compiler\stage2\build\HscStats.dyn_o" "compiler\stage2\build\InteractiveEval.dyn_o" "compiler\stage2\build\PprTyThing.dyn_o" "compil er\stage2\build\SysTools.dyn_o" "compiler\stage2\build\TidyPgm.dyn_o" "compiler\stage2\build\Ct ype.dyn_o" "compiler\stage2\build\HaddockUtils.dyn_o" "compiler\stage2\build\LexCore.dyn_o" "co mpiler\stage2\build\Lexer.dyn_o" "compiler\stage2\build\Parser.dyn_o" "compiler\stage2\build\Pa rserCore.dyn_o" "compiler\stage2\build\ParserCoreUtils.dyn_o" "compiler\stage2\build\RdrHsSyn.d yn_o" "compiler\stage2\build\PrelInfo.dyn_o" "compiler\stage2\build\ProfInit.dyn_o" "compiler\s tage2\build\SCCfinal.dyn_o" "compiler\stage2\build\RnBinds.dyn_o" "compiler\stage2\build\RnEnv. dyn_o" "compiler\stage2\build\RnExpr.dyn_o" "compiler\stage2\build\RnHsDoc.dyn_o" "compiler\sta ge2\build\RnNames.dyn_o" "compiler\stage2\build\RnPat.dyn_o" "compiler\stage2\build\RnSource.dy n_o" "compiler\stage2\build\RnTypes.dyn_o" "compiler\stage2\build\CoreMonad.dyn_o" "compiler\st age2\build\CSE.dyn_o" "compiler\stage2\build\FloatIn.dyn_o" "compiler\stage2\build\FloatOut.dyn _o" "compiler\stage2\build\LiberateCase.dyn_o" "compiler\stage2\build\SAT.dyn_o" "compiler\stag e2\build\SetLevels.dyn_o" "compiler\stage2\build\SimplCore.dyn_o" "compiler\stage2\build\SimplE nv.dyn_o" "compiler\stage2\build\SimplMonad.dyn_o" "compiler\stage2\build\SimplUtils.dyn_o" "co mpiler\stage2\build\Simplify.dyn_o" "compiler\stage2\build\SimplStg.dyn_o" "compiler\stage2\bui ld\StgStats.dyn_o" "compiler\stage2\build\UnariseStg.dyn_o" "compiler\stage2\build\SpecConstr.d yn_o" "compiler\stage2\build\Specialise.dyn_o" "compiler\stage2\build\CoreToStg.dyn_o" "compile r\stage2\build\StgLint.dyn_o" "compiler\stage2\build\DmdAnal.dyn_o" "compiler\stage2\build\Work Wrap.dyn_o" "compiler\stage2\build\WwLib.dyn_o" "compiler\stage2\build\FamInst.dyn_o" "compiler \stage2\build\Inst.dyn_o" "compiler\stage2\build\TcAnnotations.dyn_o" "compiler\stage2\build\Tc Arrows.dyn_o" "compiler\stage2\build\TcBinds.dyn_o" "compiler\stage2\build\TcClassDcl.dyn_o" "c ompiler\stage2\build\TcDefaults.dyn_o" "compiler\stage2\build\TcDeriv.dyn_o" "compiler\stage2\b uild\TcEnv.dyn_o" "compiler\stage2\build\TcExpr.dyn_o" "compiler\stage2\build\TcForeign.dyn_o" "compiler\stage2\build\TcGenDeriv.dyn_o" "compiler\stage2\build\TcGenGenerics.dyn_o" "compiler\ stage2\build\TcHsSyn.dyn_o" "compiler\stage2\build\TcHsType.dyn_o" "compiler\stage2\build\TcIns tDcls.dyn_o" "compiler\stage2\build\TcMType.dyn_o" "compiler\stage2\build\TcValidity.dyn_o" "co mpiler\stage2\build\TcMatches.dyn_o" "compiler\stage2\build\TcPat.dyn_o" "compiler\stage2\build \TcRnDriver.dyn_o" "compiler\stage2\build\TcRnMonad.dyn_o" "compiler\stage2\build\TcRnTypes.dyn _o" "compiler\stage2\build\TcRules.dyn_o" "compiler\stage2\build\TcSimplify.dyn_o" "compiler\st age2\build\TcErrors.dyn_o" "compiler\stage2\build\TcTyClsDecls.dyn_o" "compiler\stage2\build\Tc TyDecls.dyn_o" "compiler\stage2\build\TcUnify.dyn_o" "compiler\stage2\build\TcInteract.dyn_o" " compiler\stage2\build\TcCanonical.dyn_o" "compiler\stage2\build\TcSMonad.dyn_o" "compiler\stage 2\build\FunDeps.dyn_o" "compiler\stage2\build\GraphBase.dyn_o" "compiler\stage2\build\GraphColo r.dyn_o" "compiler\stage2\build\GraphOps.dyn_o" "compiler\stage2\build\GraphPpr.dyn_o" "compile r\stage2\build\IOEnv.dyn_o" "compiler\stage2\build\State.dyn_o" "compiler\stage2\build\Vectoris e\Builtins\Base.dyn_o" "compiler\stage2\build\Vectorise\Builtins\Initialise.dyn_o" "compiler\st age2\build\Vectorise\Builtins.dyn_o" "compiler\stage2\build\Vectorise\Monad\Base.dyn_o" "compil er\stage2\build\Vectorise\Monad\Naming.dyn_o" "compiler\stage2\build\Vectorise\Monad\Local.dyn_ o" "compiler\stage2\build\Vectorise\Monad\Global.dyn_o" "compiler\stage2\build\Vectorise\Monad\ InstEnv.dyn_o" "compiler\stage2\build\Vectorise\Monad.dyn_o" "compiler\stage2\build\Vectorise\U tils\Base.dyn_o" "compiler\stage2\build\Vectorise\Utils\Closure.dyn_o" "compiler\stage2\build\V ectorise\Utils\Hoisting.dyn_o" "compiler\stage2\build\Vectorise\Utils\PADict.dyn_o" "compiler\s tage2\build\Vectorise\Utils\Poly.dyn_o" "compiler\stage2\build\Vectorise\Utils.dyn_o" "compiler \stage2\build\Vectorise\Generic\Description.dyn_o" "compiler\stage2\build\Vectorise\Generic\PAM ethods.dyn_o" "compiler\stage2\build\Vectorise\Generic\PADict.dyn_o" "compiler\stage2\build\Vec torise\Generic\PData.dyn_o" "compiler\stage2\build\Vectorise\Type\Env.dyn_o" "compiler\stage2\b uild\Vectorise\Type\Type.dyn_o" "compiler\stage2\build\Vectorise\Type\TyConDecl.dyn_o" "compile r\stage2\build\Vectorise\Type\Classify.dyn_o" "compiler\stage2\build\Vectorise\Convert.dyn_o" " compiler\stage2\build\Vectorise\Vect.dyn_o" "compiler\stage2\build\Vectorise\Var.dyn_o" "compil er\stage2\build\Vectorise\Env.dyn_o" "compiler\stage2\build\Vectorise\Exp.dyn_o" "compiler\stag e2\build\Vectorise.dyn_o" "compiler\stage2\build\AsmCodeGen.dyn_o" "compiler\stage2\build\Targe tReg.dyn_o" "compiler\stage2\build\NCGMonad.dyn_o" "compiler\stage2\build\Instruction.dyn_o" "c ompiler\stage2\build\Size.dyn_o" "compiler\stage2\build\PIC.dyn_o" "compiler\stage2\build\CPrim .dyn_o" "compiler\stage2\build\X86\Regs.dyn_o" "compiler\stage2\build\X86\RegInfo.dyn_o" "compi ler\stage2\build\X86\Instr.dyn_o" "compiler\stage2\build\X86\Cond.dyn_o" "compiler\stage2\build \X86\Ppr.dyn_o" "compiler\stage2\build\X86\CodeGen.dyn_o" "compiler\stage2\build\PPC\Regs.dyn_o " "compiler\stage2\build\PPC\RegInfo.dyn_o" "compiler\stage2\build\PPC\Instr.dyn_o" "compiler\s tage2\build\PPC\Cond.dyn_o" "compiler\stage2\build\PPC\Ppr.dyn_o" "compiler\stage2\build\PPC\Co deGen.dyn_o" "compiler\stage2\build\SPARC\Base.dyn_o" "compiler\stage2\build\SPARC\Regs.dyn_o" "compiler\stage2\build\SPARC\Imm.dyn_o" "compiler\stage2\build\SPARC\AddrMode.dyn_o" "compiler\ stage2\build\SPARC\Cond.dyn_o" "compiler\stage2\build\SPARC\Instr.dyn_o" "compiler\stage2\build \SPARC\Stack.dyn_o" "compiler\stage2\build\SPARC\ShortcutJump.dyn_o" "compiler\stage2\build\SPA RC\Ppr.dyn_o" "compiler\stage2\build\SPARC\CodeGen.dyn_o" "compiler\stage2\build\SPARC\CodeGen\ Amode.dyn_o" "compiler\stage2\build\SPARC\CodeGen\Base.dyn_o" "compiler\stage2\build\SPARC\Code Gen\CondCode.dyn_o" "compiler\stage2\build\SPARC\CodeGen\Gen32.dyn_o" "compiler\stage2\build\SP ARC\CodeGen\Gen64.dyn_o" "compiler\stage2\build\SPARC\CodeGen\Sanity.dyn_o" "compiler\stage2\bu ild\SPARC\CodeGen\Expand.dyn_o" "compiler\stage2\build\RegAlloc\Liveness.dyn_o" "compiler\stage 2\build\RegAlloc\Graph\Main.dyn_o" "compiler\stage2\build\RegAlloc\Graph\Stats.dyn_o" "compiler \stage2\build\RegAlloc\Graph\ArchBase.dyn_o" "compiler\stage2\build\RegAlloc\Graph\ArchX86.dyn_ o" "compiler\stage2\build\RegAlloc\Graph\Coalesce.dyn_o" "compiler\stage2\build\RegAlloc\Graph\ Spill.dyn_o" "compiler\stage2\build\RegAlloc\Graph\SpillClean.dyn_o" "compiler\stage2\build\Reg Alloc\Graph\SpillCost.dyn_o" "compiler\stage2\build\RegAlloc\Graph\TrivColorable.dyn_o" "compil er\stage2\build\RegAlloc\Linear\Main.dyn_o" "compiler\stage2\build\RegAlloc\Linear\JoinToTarget s.dyn_o" "compiler\stage2\build\RegAlloc\Linear\State.dyn_o" "compiler\stage2\build\RegAlloc\Li near\Stats.dyn_o" "compiler\stage2\build\RegAlloc\Linear\FreeRegs.dyn_o" "compiler\stage2\build \RegAlloc\Linear\StackMap.dyn_o" "compiler\stage2\build\RegAlloc\Linear\Base.dyn_o" "compiler\s tage2\build\RegAlloc\Linear\X86\FreeRegs.dyn_o" "compiler\stage2\build\RegAlloc\Linear\X86_64\F reeRegs.dyn_o" "compiler\stage2\build\RegAlloc\Linear\PPC\FreeRegs.dyn_o" "compiler\stage2\buil d\RegAlloc\Linear\SPARC\FreeRegs.dyn_o" "compiler\stage2\build\DsMeta.dyn_o" "compiler\stage2\b uild\TcSplice.dyn_o" "compiler\stage2\build\Convert.dyn_o" "compiler\stage2\build\ByteCodeGen.d yn_o" "compiler\stage2\build\Debugger.dyn_o" "compiler\stage2\build\LibFFI.dyn_o" "compiler\sta ge2\build\Linker.dyn_o" "compiler\stage2\build\RtClosureInspect.dyn_o" "compiler\stage2\build\D ebuggerUtils.dyn_o" "compiler\stage2\build\parser\cutils.dyn_o" "compiler\stage2\build\ghci\kee pCAFsForGHCi.dyn_o" "compiler\stage2\build\cbits\genSym.dyn_o" "-lHSghc-7.7.20130904-0-ghc7.7.2 0130904.dll" "-Lcompiler/stage2/build" "-Lc:\Users\ezyang\Dev\ghc- validate\libraries\transforme rs\dist-install\build" "-Lc:\Users\ezyang\Dev\ghc-validate\libraries \template-haskell\dist-inst all\build" "-Lc:\Users\ezyang\Dev\ghc-validate\libraries\hpc\dist- install\build" "-Lc:\Users\ez yang\Dev\ghc-validate\libraries\hoopl\dist-install\build" "-Lc:\Users\ezyang\Dev\ghc-validate\l ibraries\bin-package-db\dist-install\build" "-Lc:\Users\ezyang\Dev\ghc- validate\libraries\binar y\dist-install\build" "-Lc:\Users\ezyang\Dev\ghc- validate\libraries\Cabal\Cabal\dist-install\bu ild" "-Lc:\Users\ezyang\Dev\ghc-validate\libraries\process\dist- install\build" "-Lc:\Users\ezya ng\Dev\ghc-validate\libraries\pretty\dist-install\build" "-Lc:\Users\ezyang\Dev\ghc-validate\li braries\directory\dist-install\build" "-Lc:\Users\ezyang\Dev\ghc- validate\libraries\time\dist-i nstall\build" "-Lc:\Users\ezyang\Dev\ghc-validate\libraries\old-locale \dist-install\build" "-Lc :\Users\ezyang\Dev\ghc-validate\libraries\filepath\dist-install\build" "-Lc:\Users\ezyang\Dev\g hc-validate\libraries\Win32\dist-install\build" "-Lc:\Users\ezyang\Dev \ghc-validate\libraries\c ontainers\dist-install\build" "-Lc:\Users\ezyang\Dev\ghc- validate\libraries\bytestring\dist-ins tall\build" "-Lc:\Users\ezyang\Dev\ghc-validate\libraries\deepseq\dist- install\build" "-Lc:\Use rs\ezyang\Dev\ghc-validate\libraries\array\dist-install\build" "-Lc:\Users\ezyang\Dev\ghc-valid ate\libraries\base\dist-install\build" "-Lc:\Users\ezyang\Dev\ghc- validate\libraries\integer-gm p\dist-install\build" "-Lc:\Users\ezyang\Dev\ghc-validate\libraries\ghc- prim\dist-install\build " "-Lc:/Users/ezyang/Dev/ghc-validate/rts/dist/build" "-lHStransformers-0.3.0.0-ghc7.7.20130904 " "-lHStemplate-haskell-2.9.0.0-ghc7.7.20130904" "-lHShpc-0.6.0.1-ghc7.7.20130904" "-lHShoopl-3 .10.0.0-ghc7.7.20130904" "-lHSbin-package-db-0.0.0.0-ghc7.7.20130904" "-lHSbinary-0.7.1.0-ghc7. 7.20130904" "-lHSCabal-1.18.0-ghc7.7.20130904" "-lHSprocess-1.2.0.0-ghc7.7.20130904" "-lHSprett y-1.1.1.0-ghc7.7.20130904" "-lHSdirectory-1.2.0.1-ghc7.7.20130904" "-lHStime-1.4.1-ghc7.7.20130 904" "-lHSold-locale-1.0.0.5-ghc7.7.20130904" "-lHSfilepath-1.3.0.2-ghc7.7.20130904" "-lHSWin32 -2.3.0.0-ghc7.7.20130904" "-lHScontainers-0.5.2.1-ghc7.7.20130904" "-lHSbytestring-0.10.3.0-ghc 7.7.20130904" "-lHSdeepseq-1.3.0.2-ghc7.7.20130904" "-lHSarray-0.4.0.2-ghc7.7.20130904" "-lHSba se-4.7.0.0-ghc7.7.20130904" "-lHSinteger-gmp-0.5.1.0-ghc7.7.20130904" "-lHSghc-prim-0.3.1.0-ghc 7.7.20130904" "-lHSrts_thr-ghc7.7.20130904" "-lffi-6" "-lkernel32" "-luser32" "-lgdi32" "-lwinm m" "-ladvapi32" "-lshell32" "-lshfolder" "-lwsock32" "-luser32" "-lshell32" "-lm" "-lwsock32" " -lgdi32" "-lwinmm" "-lmingwex" "-Wl,-u,_ghczmprim_GHCziTypes_Izh_static_info" "-Wl,-u,_ghczmpri m_GHCziTypes_Czh_static_info" "-Wl,-u,_ghczmprim_GHCziTypes_Fzh_static_info" "-Wl,-u,_ghczmprim _GHCziTypes_Dzh_static_info" "-Wl,-u,_base_GHCziPtr_Ptr_static_info" "-Wl,-u,_ghczmprim_GHCziTy pes_Wzh_static_info" "-Wl,-u,_base_GHCziInt_I8zh_static_info" "-Wl,-u,_base_GHCziInt_I16zh_stat ic_info" "-Wl,-u,_base_GHCziInt_I32zh_static_info" "-Wl,-u,_base_GHCziInt_I64zh_static_info" "- Wl,-u,_base_GHCziWord_W8zh_static_info" "-Wl,-u,_base_GHCziWord_W16zh_static_info" "-Wl,-u,_bas e_GHCziWord_W32zh_static_info" "-Wl,-u,_base_GHCziWord_W64zh_static_info" "-Wl,-u,_base_GHCziSt able_StablePtr_static_info" "-Wl,-u,_ghczmprim_GHCziTypes_Izh_con_info" "-Wl,-u,_ghczmprim_GHCz iTypes_Czh_con_info" "-Wl,-u,_ghczmprim_GHCziTypes_Fzh_con_info" "-Wl,-u,_ghczmprim_GHCziTypes_ Dzh_con_info" "-Wl,-u,_base_GHCziPtr_Ptr_con_info" "-Wl,-u,_base_GHCziPtr_FunPtr_con_info" "-Wl ,-u,_base_GHCziStable_StablePtr_con_info" "-Wl,-u,_ghczmprim_GHCziTypes_False_closure" "-Wl,-u, _ghczmprim_GHCziTypes_True_closure" "-Wl,-u,_base_GHCziPack_unpackCString_closure" "-Wl,-u,_bas e_GHCziIOziException_stackOverflow_closure" "-Wl,-u,_base_GHCziIOziException_heapOverflow_closu re" "-Wl,-u,_base_ControlziExceptionziBase_nonTermination_closure" "-Wl,-u,_base_GHCziIOziExcep tion_blockedIndefinitelyOnMVar_closure" "-Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnS TM_closure" "-Wl,-u,_base_ControlziExceptionziBase_nestedAtomically_closure" "-Wl,-u,_base_GHCz iWeak_runFinalizzerBatch_closure" "-Wl,-u,_base_GHCziTopHandler_flushStdHandles_closure" "-Wl,- u,_base_GHCziTopHandler_runIO_closure" "-Wl,-u,_base_GHCziTopHandler_runNonIO_closure" "-Wl,-u, _base_GHCziConcziIO_ensureIOManagerIsRunning_closure" "-Wl,-u,_base_GHCziConcziIO_ioManagerCapa bilitiesChanged_closure" "-Wl,-u,_base_GHCziConcziSync_runSparks_closure" "-Wl,-u,_base_GHCziCo ncziSignal_runHandlers_closure" "-Wl,--hash-size=31" "-Wl,--reduce-memory- overheads" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8229> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8127: iOS patch no 19: Linking
by GHC 05 Sep '15

05 Sep '15

#8127: iOS patch no 19: Linking -------------------------------------+------------------------------------- Reporter: StephenBlackheath | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Other Architecture: arm | Type of failure: GHC doesn't work Difficulty: Moderate (less | at all than a day) | Test Case: Blocked By: | Blocking: 7724 Related Tickets: | -------------------------------------+------------------------------------- Fix linking for cross compiler to iOS. This patch does these things: 1. use libtool to link to a static library in place of an executable (because on iOS the final link must be done in Xcode), 2. for packages, keep only the HS package libraries and throw out other options (because libtool doesn't accept them), 3. fail if you try to link a dynamic library on iOS because it isn't supported (not really needed but there for completeness). Note that there is a minor risk here, because in the normal case, the order of options passed to the linker is slightly different: The options relating to each dependent package are separated into three different kinds, but they're still in the same relative order per package. This should be perfectly OK. The name of "libtool" is hard-coded and can't be set by options. Is this OK? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8127> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #9943: Replace "error" with "errorWithStackTrace" from GHC.Stack in base libs
by GHC 04 Sep '15

04 Sep '15

#9943: Replace "error" with "errorWithStackTrace" from GHC.Stack in base libs -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh spacekitteh | Status: new Type: task | Milestone: 7.10.1 Priority: normal | Version: Component: Core | Operating System: Unknown/Multiple Libraries | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- It is basically the same as the standard error function but outputs a stack trace if one is available. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9943> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10047: inconsistency in name binding between splice and quasiquotation
by GHC 04 Sep '15

04 Sep '15

#10047: inconsistency in name binding between splice and quasiquotation -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.4 Haskell | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Let me preface this by saying that this may not be a bug. If not then it would be nice if the documentation for Template Haskell could clarify what's going on here. My understanding of quasiquotation is that a quasiquote `[n|foo|]` is equivalent to a splice `$(quoteExp n "foo")`. However, that is not the case in all contexts. {{{ module Q where import Language.Haskell.TH import Language.Haskell.TH.Quote n = QuasiQuoter { quoteExp = dyn } }}} {{{ rwbarton@morphism:/tmp$ ghci -XTemplateHaskell -XQuasiQuotes Q GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Q ( Q.hs, interpreted ) Q.hs:6:5: Warning: Fields of ‘QuasiQuoter’ not initialised: quotePat, quoteType, quoteDec In the expression: QuasiQuoter {quoteExp = dyn} In an equation for ‘n’: n = QuasiQuoter {quoteExp = dyn} Ok, modules loaded: Q. *Q> :t [| $(dyn "foo") |] [| $(dyn "foo") |] :: ExpQ *Q> :t [| [n|foo|] |] Loading package pretty-1.1.1.1 ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package template-haskell ... linking ... done. <interactive>:1:7: Not in scope: ‘foo’ In the Template Haskell quotation [| [n|foo|] |] }}} Why do these behave differently? (Lastly, the link to the paper "Why It's Nice to be Quoted: Quasiquoting for Haskell" in the User's Guide at https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/template- haskell.html#th-quasiquotation is broken. Does this paper have a permanent home? In any case, I only skimmed it but it didn't seem to answer my question.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10047> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #10541: Expose kind information for type variables with reify
by GHC 01 Sep '15

01 Sep '15

#10541: Expose kind information for type variables with reify -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Template | Operating System: Unknown/Multiple Haskell | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The comment on [https://hackage.haskell.org/package/template- haskell-2.10.0.0/docs/Language-Haskell-TH-Syntax.html#v:TyVarI TyVarI] notes that the attached Type is always {{{VarT theName}}}, and that this could potentially be extended. Currently, there isn't a way to access kind information for a type variable through the Template Haskell API. It would be useful (at least for me) to have this ability here. The limitation on the returned Type comes from the [https://github.com/ghc/ghc/blob/master/compiler/typecheck/TcSplice.hs#L1060 ATyVar clause of reifyThing], which zonks the TyVar to a GHC type and then uses reifyType to convert it to a TH type. For a TyVarTy, [https://github.com/ghc/ghc/blob/master/compiler/typecheck/TcSplice.hs#L1281 reifyType] always returns {{{VarT theName}}}. I can see a few possible ways of exposing kind information here: (a) Fill the Type argument to TyVarI with {{{SigT (VarT theName) theKind}}}. This could be done either as a special case in place of the call to reifyType in reifyThing, or as a modification to reifyType's behavior. The question of when SigT should be included is open: all the time? when the kind isn't {{{*}}}? when the kind is something that involves more than {{{*}}} and {{{->}}}? (b) Change TyVarI from {{{TyVarI Name Type}}} to {{{TyVarI Name TyVarBndr}}}. This seems like the most straightforward, stable way of exposing kind information, but it requires a breaking API change. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10541> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 31 Aug '15

31 Aug '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192 -------------------------------------+------------------------------------- Comment (by Simon Marlow <marlowsd@…>): In [changeset:"10a07753ff4ac0c1285454567c926d580d0f0470/ghc" 10a0775/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="10a07753ff4ac0c1285454567c926d580d0f0470" Anchor type family instances deterministically Summary: This is very similar to D1073. It makes type family instances to be attached to a binding with a least `OccName`, therefore not depending on `Unique` ordering. Test Plan: * this makes `Language.Haskell.Exts.SrcLoc` deterministic * ./validate Reviewers: simonmar, austin, bgamari, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1192 GHC Trac Issues: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:116> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0