- ghc-tickets - Haskell.org

[GHC] #7813: Fix mismatched visibility of StgRun
by GHC 27 Apr '13

27 Apr '13

#7813: Fix mismatched visibility of StgRun --------------------------------+------------------------------------------- Reporter: PHO | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- [http://www.haskell.org/pipermail/ghc-devs/2013-April/000932.html From Gabor Greif]: {{{ I am getting linker errors when bootstrapping HEAD with a recent v7.7-20130220 GHC. This is a RHEL5 system: "inplace/bin/ghc-stage1" -package-name rts -shared -dynamic -dynload deploy -no-auto-link-packages -Lrts/dist/build -lffi -optl-Wl,-rpath -optl-Wl,'$ORIGIN' `cat rts/libs.depend` <<snip>> rts/dist/build/AutoApply.debug_dyn_o -o rts/dist/build/libHSrts_debug-ghc7.7.20130402.so /usr/bin/ld: rts/dist/build/Schedule.dyn_o: relocation R_X86_64_PC32 against `StgRun' 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 }}} [http://www.haskell.org/pipermail/ghc-devs/2013-April/000966.html From PHO]: {{{ The old binutils comes with RHEL5 fails to link a shared library if there is a reference to a hidden symbol that isn't locally defined. See: https://gist.github.com/phonohawk/5308015 Personally I don't think this is an old binutils' fault, because the newer one is essentially turning an otherwise global symbol to a local one depending on its call site, which feels rather wrong to me. The attached patch should fix the problem anyway. }}} From Gabor Greif: {{{ Thanks a lot! This worked, but now we have the libffi-related problem on install: /home/ggreif/lib/ghc-7.7.20130403/bin/ghc-pkg: error while loading shared libraries: libHSterminfo-0.3.2.5-ghc7.7.20130403.so: cannot open shared object file: No such file or directory make[1]: *** [install_packages] Error 127 This is described in another mail thread, so I'll relax now. }}} My patch is to change the visibility of `StgRun`/`StgReturn` for each and every platforms, but I've only tested it on my NetBSD/amd64, Linux/x86_64 and FreeBSD/i386 boxes. I hope I've not broken other platforms namely Darwin/i386, Darwin/x86_64, Darwin/PPC32, Linux/PPC32, Linux/PPC64, Linux/ARM, iOS/ARM and Sparc. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7813> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #7823: ARM Thumb relocation fails to handle sign of veneer jumps
by GHC 27 Apr '13

27 Apr '13

#7823: ARM Thumb relocation fails to handle sign of veneer jumps --------------------------+------------------------------------------------- Reporter: cjwatson | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.6.2 | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: Runtime crash | Blockedby: Blocking: | Related: --------------------------+------------------------------------------------- While working on http://hackage.haskell.org/trac/ghc/ticket/7794 on Linux/ARM (ARMv7, hard float), I found that 'inplace/bin/ghc-stage2 --interactive' was raising various signals along the lines of SIGSEGV/SIGILL on startup. Considerable hair-pulling and gdb later, I found that this was a jump into space when it should have been jumping to nl_langinfo from localeEncoding in base. After even more poking around with gdb, I've tracked this down to a linker bug and have a patch. When the linker processes an R_ARM_THM_CALL or R_ARM_THM_JUMP24 relocation, it sometimes needs to generate a "veneer" jump target if the true destination is out of range. This is done almost entirely correctly. However, it reuses the sign bit decoded from the original instruction when re-encoding. This means that if the veneer is on the opposite side of the branch instruction from the unrelocated target, the branch target will be encoded incorrectly. This is a common case since the veneer is typically generated after the code being relocated but a to-be-relocated R_ARM_THM_CALL instruction will typically be a branch to PC-4 (a.k.a. the branch source itself). The simple, and I hope obvious, fix is to compute the sign from the new offset. The attached patch should apply to both master and ghc-7.6. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7823> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #1896: Keep old bindings until :load succeeds
by GHC 26 Apr '13

26 Apr '13

#1896: Keep old bindings until :load succeeds -------------------------------+-------------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: closed Priority: low | Milestone: 7.6.2 Component: GHCi | Version: 6.8.1 Resolution: wontfix | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by igloo): * status: patch => closed * resolution: => wontfix Comment: For the `:reload` case, I don't think we want to fall back to the previous state if the reload fails. For example, suppose you have `A` and `B` loaded, `B` imports `A`, and you make a change to `A` and reload. If `B` is no longer well-typed, then I think you want to end up with the new `A` loaded so that you can see how to fix `B`. I'm going to close this ticket, but if anyone thinks there's a case that should be handled differently than it currently is, please open a new ticket and include step by step instructions to demonstrate the current (wrong) behaviour, and say what you think the right behaviour should be. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1896#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7864: --make -dynamic-too doesn't work
by GHC 26 Apr '13

26 Apr '13

#7864: --make -dynamic-too doesn't work ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ `--make -dynamic-too` doesn't work yet. I think that the best fix will be to unify the two different code paths that `-c` and `--make` use to do more-or-less the same thing (the Hsc phase). In the mean-time, this means that Cabal can't use -dynamic-too, so I've marked it as not supported in `compilerInfo` in `DynFlags`. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7864> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7846: GHC 7.7 cannot link primitives
by GHC 26 Apr '13

26 Apr '13

#7846: GHC 7.7 cannot link primitives -----------------------------------------+---------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Compile-time performance bug | Blockedby: Blocking: | Related: -----------------------------------------+---------------------------------- When I tries to install the vector library on Linux, GHC 7.7 cannot find a necessary primitive library: {{{ % cabal install vector ... [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic ( Data/Vector/Fusion/Stream/Monadic.hs, dist/build/Data/Vector/Fusion/Stream/Monadic.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package primitive-0.5.0.1 ... <command line>: can't load .so/.DLL for: libHSprimitive-0.5.0.1.so (libHSprimitive-0.5.0.1.so: cannot open shared object file: No such file or directory) cabal: Error: some packages failed to install: vector-0.10.0.1 failed during the building phase. The exception was: ExitFailure 1 }}} Note that static library of primitive is installed but dynamic one is not. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7846> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7530: Proposal: Add isLeft/isRight to Data.Either
by GHC 26 Apr '13

26 Apr '13

#7530: Proposal: Add isLeft/isRight to Data.Either -------------------------------+-------------------------------------------- Reporter: SimonHengel | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by igloo): * status: patch => closed * resolution: => fixed Comment: Applied, thanks! {{{ commit 58d03b8ed4342b80bd0ed8afa52c2b5c7f975534 Author: Simon Hengel <sol(a)typeful.net> Date: Tue Dec 25 16:07:27 2012 +0100 Add isLeft/isRight }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7530#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7327: Inconsistent behavior for relative paths in runProcess
by GHC 25 Apr '13

25 Apr '13

#7327: Inconsistent behavior for relative paths in runProcess ----------------------------------+----------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: libraries/process | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ----------------------------------+----------------------------------------- Comment(by igloo): Are you sure that's a segfault, rather than an error because the shell scripts aren't executable? If so, do you know which process is segfaulting? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7327#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7327: Inconsistent behavior for relative paths in runProcess
by GHC 25 Apr '13

25 Apr '13

#7327: Inconsistent behavior for relative paths in runProcess ----------------------------------+----------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: libraries/process | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ----------------------------------+----------------------------------------- Changes (by tibbe): * cc: johan.tibell@… (added) Comment: I tried to reproduce the problem, but unfortunately I get a segfault!: {{{ $ cd tmp $ cat > q.hs import System.Process main :: IO () main = do ph <- runProcess "./runme.sh" [] (Just "sub") Nothing Nothing Nothing Nothing ec <- waitForProcess ph print ec $ cat > runme.sh #!/bin/sh echo Running root $ mkdir sub $ cat > sub/runme.sh #!/bin/sh echo Running in sub $ ghc --make q [1 of 1] Compiling Main ( q.hs, q.o ) Linking q ... $ ./q ExitFailure 127 $ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","/usr/bin/gcc") ,("C compiler flags"," -m64 -fno-stack-protector -m64") ,("ar command","/usr/bin/ar") ,("ar flags","clqs") ,("ar supports at file","@ArSupportsAtFile@") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("perl command","/usr/bin/perl") ,("target os","OSDarwin") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","True") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.6.2") ,("Booter version","7.4.2") ,("Stage","2") ,("Build platform","x86_64-apple-darwin") ,("Host platform","x86_64-apple-darwin") ,("Target platform","x86_64-apple-darwin") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Unregisterised","NO") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn") ,("Leading underscore","YES") ,("Debug on","False") ,("LibDir","/usr/local/lib/ghc-7.6.2") ,("Global Package DB","/usr/local/lib/ghc-7.6.2/package.conf.d") ,("Gcc Linker flags","[\"-m64\"]") ,("Ld Linker flags","[\"-arch\",\"x86_64\"]") ] }}} OS X 10.8.3. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7327#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4215: canonicalizePath behaves strangely with paths that do not exist
by GHC 25 Apr '13

25 Apr '13

#4215: canonicalizePath behaves strangely with paths that do not exist ------------------------------------+--------------------------------------- Reporter: creswick | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: libraries/directory | Version: 6.12.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Incorrect result at runtime Difficulty: | Testcase: Blockedby: | Blocking: Related: | ------------------------------------+--------------------------------------- Changes (by refold): * cc: the.dead.shall.rise@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4215#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5013: sporadic failures during compilation under solaris
by GHC 25 Apr '13

25 Apr '13

#5013: sporadic failures during compilation under solaris ----------------------------+----------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.0.4 Resolution: | Keywords: Os: Solaris | Architecture: x86 Failure: Runtime crash | Difficulty: Testcase: | Blockedby: Blocking: | Related: ----------------------------+----------------------------------------------- Comment(by maeder): Does the following message give any hint what might go wrong? {{{ ghc-pkg: /home/pub-bkb/pc- solaris/ghc/ghc-7.6.2/lib/ghc-7.6.2/package.conf.d: getFileStatus: interrupted (Interrupted system call) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5013#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0