- ghc-devs - Haskell.org

[PATCH 2/2] fix binary linking errors on Solaris due to misplacing of -Wl, -u, <symbol> option
by Karel Gardas 12 Jan '14

12 Jan '14

--- compiler/main/DriverPipeline.hs | 11 ++++++++++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/compiler/main/DriverPipeline.hs b/compiler/main/DriverPipeline.hs index 337778e..1c593b6 100644 --- a/compiler/main/DriverPipeline.hs +++ b/compiler/main/DriverPipeline.hs @@ -1790,7 +1790,16 @@ linkBinary' staticLink dflags o_files dep_packages = do -- HS packages, because libtool doesn't accept other options. -- In the case of iOS these need to be added by hand to the -- final link in Xcode. - else package_hs_libs ++ extra_libs ++ other_flags + else other_flags ++ package_hs_libs ++ extra_libs -- -Wl,-u,<sym> contained in other_flags + -- needs to be put before -l<package>, + -- otherwise Solaris linker fails linking + -- a binary with unresolved symbols in RTS + -- which are defined in base package + -- the reason for this is a note in ld(1) about + -- '-u' option: "The placement of this option + -- on the command line is significant. + -- This option must be placed before the library + -- that defines the symbol." pkg_framework_path_opts <- if platformUsesFrameworks platform -- 1.7.3.2

1 0

[PATCH 1/2] add handling of Solaris linker into SysTools
by Karel Gardas 12 Jan '14

12 Jan '14

--- compiler/main/DynFlags.hs | 1 + compiler/main/SysTools.lhs | 9 +++++++++ 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/compiler/main/DynFlags.hs b/compiler/main/DynFlags.hs index 70d2a81..e253bae 100644 --- a/compiler/main/DynFlags.hs +++ b/compiler/main/DynFlags.hs @@ -3721,6 +3721,7 @@ data LinkerInfo = GnuLD [Option] | GnuGold [Option] | DarwinLD [Option] + | SolarisLD [Option] | UnknownLD deriving Eq diff --git a/compiler/main/SysTools.lhs b/compiler/main/SysTools.lhs index 46f8a86..0c86c18 100644 --- a/compiler/main/SysTools.lhs +++ b/compiler/main/SysTools.lhs @@ -638,6 +638,7 @@ neededLinkArgs :: LinkerInfo -> [Option] neededLinkArgs (GnuLD o) = o neededLinkArgs (GnuGold o) = o neededLinkArgs (DarwinLD o) = o +neededLinkArgs (SolarisLD o) = o neededLinkArgs UnknownLD = [] -- Grab linker info and cache it in DynFlags. @@ -676,6 +677,14 @@ getLinkerInfo' dflags = do -- Process the executable call info <- catchIO (do case os of + OSSolaris2 -> + -- Solaris uses its own Solaris linker. Even all + -- GNU C are receommended to configure with Solaris + -- linker instead of using GNU binutils linker. Also + -- all GCC distributed with Solaris follows this rule + -- precisely so we assume here, the Solaris linker is + -- used. + return $ SolarisLD [] OSDarwin -> -- Darwin has neither GNU Gold or GNU LD, but a strange linker -- that doesn't support --version. We can just assume that's -- 1.7.3.2

1 0

Validating with Haddock
by Mateusz Kowalczyk 12 Jan '14

12 Jan '14

Greetings, I'm trying to validate HEAD and I care that Haddock is built alongside it (so --no-haddock is not an option). I get the following errors listed at the bottom of this e-mail. How can I validate so that it all builds? >From what I understand, to validate I should: * Have a stable compiler in my PATH (7.6.3) * go to top level directory * run ‘sh validate’ Am I missing steps? == Start post-build package check Timestamp 2013-12-28 05:00:55 UTC for /home/shana/.ghc/i386-linux-7.7.20131227/package.conf.d/package.cache Timestamp 2013-12-28 05:00:55 UTC for /home/shana/.ghc/i386-linux-7.7.20131227/package.conf.d (same as cache) using cache: /home/shana/.ghc/i386-linux-7.7.20131227/package.conf.d/package.cache Timestamp 2013-12-28 05:22:27 UTC for /home/shana/programming/ghc/inplace/lib/package.conf.d/package.cache Timestamp 2013-12-28 05:22:27 UTC for /home/shana/programming/ghc/inplace/lib/package.conf.d (same as cache) using cache: /home/shana/programming/ghc/inplace/lib/package.conf.d/package.cache There are problems in package xhtml-3000.2.1: dependency "base-4.7.0.0-578628bf142f9304d05ce5581b5f8d76" doesn't exist There are problems in package ghc-paths-0.1.0.9: dependency "base-4.7.0.0-578628bf142f9304d05ce5581b5f8d76" doesn't exist The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. xhtml-3000.2.1 ghc-paths-0.1.0.9 -- Mateusz K.

5 23

HEADS-UP: testsuite has been folded into ghc; back up your old testsuite/ folder!
by Herbert Valerio Riedel 12 Jan '14

12 Jan '14

Hello *, It's finally done; effective immediately, the testsuite/ folder is now tracked as part of ghc.git (for the master branch) *IMPORTANT* If there's any chance you have something importing lying around in your testsuite/ please move it out of the way preemptively (e.g. with 'mv testsuite/ testsuite-old/') *before* you perform a 'git pull' or 'sync-all pull' on ghc.git. Even though there are some safe-guards in place, those might not be 100% effective, so better safe than sorry. As only the `master` branch of testsuite.git has been merged, those of you who had wip/ branches or similar in testsuite.git need to handle those yourselves. Should you need assistance with bringing over those commits from testsuite.git into ghc.git (or if there's anything else that's now broken because of this change), please let me and/or Austin a line, so we can assist you. See also previous post "Folding ghc/testsuite repos *now*, 2nd attempt"[1] announcing this step. [1] http://www.haskell.org/pipermail/ghc-devs/2014-January/003730.html Greetings, hvr

1 0

Repository Reorganization Question
by Austin Seipp 11 Jan '14

11 Jan '14

Hi all, While discussing something with Herbert this week in preparation of making a new stable branch, he brought a good point to my attention, which is that if we go ahead and reorganize the repository situation post 7.8, merging things to the stable branch from HEAD will become a bit harder. Notably, we had planned to fold testsuite (and perhaps some other repositories) into the GHC tree. Once we do this, the two branches will have diverged quite a bit, so merging from HEAD to STABLE will become harder* (because HEAD would have rolled in testsuite changes for example, but the STABLE branch would not have this history.) Thinking about it, the best time to do such a move is, basically, when there is no active stable branch. Unfortunately this time is right now, but I'm not sure how everyone feels about this. So, the question is: should we go ahead and pull the trigger on some of these perhaps? Herbert collected some numbers on the git repositories and outlined all the basic details here: https://ghc.haskell.org/trac/ghc/wiki/GitRepoReorganization The only thing I'd honestly propose right now is folding 'testsuite' into the main repository, but of course we should see what people think - perhaps we should keep base/etc off the table for now, since they seem more controversial. * I'll point out they will only become *slightly* harder in most cases, because I can always instead apply unified diffs, rather than cherry pick or something. But it does lose the original metadata from commits too. But I won't cry if people vote against this. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

13 43

Fwd: Changing GHC Error Message Wrapping
by Andrew Gibiansky 10 Jan '14

10 Jan '14

Hello, I'd like to change how the error messages from GHC get wrapped. I am using the following code: flip gcatch handler $ do runStmt "let f (x, y, z, w, e, r, d , ax, b ,c,ex ,g ,h) = (x :: Int) + y + z" RunToCompletion runStmt "f (1, 2, 3)" RunToCompletion return () where handler :: SomeException -> Ghc () handler e = liftIO $ putStrLn $ "Exception:\n" ++ show e The output I am getting looks like this: [image: Inline image 1] I would like the types to not wrap at all, or wrap at some very long length along the lines of 200-300 characters. I have seen the `pprUserLength` and `pprCols` fields in DynFlags, but they don't seem to do anything. What should I do? Thanks! Andrew

5 12

Optimisation flags at -O0
by Chris Heller 09 Jan '14

09 Jan '14

I wanted to understand better what `-fspec-constr` does. So I compiled the User Guide example with `-O0 -fspec-constr` to isolate the effects of call-pattern specialization, and nothing else (I used ghc-core to pretty-print the resulting Core syntax). It appears I get the same output wether I use `-fspec-constr` or not. Does this mean that compiling with `-O0` even explicitly enabled optimizations are turned off? If that is the case, how does one test an isolated optimization? -Chris

3 2

Cannot find normal object file when compiling TH code
by Yorick Laupa 09 Jan '14

09 Jan '14

Hi, Oddly I can't compile code using TH with GHC HEAD. Here's what I get: cannot find normal object file './Tuple.dyn_o' while linking an interpreted expression I'm currently working on a issue so I compile the code with ghc-stage2 for convenience. I found an old ticket related to my problem ( https://ghc.haskell.org/trac/ghc/ticket/8443) but adding -XTemplateHaskell didn't work out. The code compiles with ghc 7.6.3. Here's my setup: Archlinux (3.12.6-1) Any suggestions ? --Yorick

3 6

Tuple predicates in Template Haskell
by Yorick Laupa 08 Jan '14

08 Jan '14

Hi, I try to make my way through #7021 [1]. Unfortunately, there is nothing in the ticket about what should be expected from the code given as example. I came with an implementation and I would like feedback from you guys. So, considering this snippet: -- {-# LANGUAGE ConstraintKinds #-} type IOable a = (Show a, Read a) foo :: IOable a => a foo = undefined -- This is what I got now when pretty-printing TH.Info after reify "foo" call: VarI Tuple.foo (ForallT [PlainTV a_1627398594] [TupleP 2 [AppT (ConT GHC.Show.Show) (VarT a_1627398594),AppT (ConT GHC.Read.Read) (VarT a_1627398594)]] (VarT a_1627398594)) Nothing (Fixity 9 InfixL) Does that sound right to you ? Thanks for your time -- Yorick [1] https://ghc.haskell.org/trac/ghc/ticket/7021

2 2

LLVM and dynamic linking
by Ben Gamari 08 Jan '14

08 Jan '14

# The Problem Dynamic linking is currently broken with the LLVM code generator. This can be easily seen by attempting to compile GHC with, GhcDynamic = YES DYNAMIC_BY_DEFAULT = YES DYNAMIC_GHC_PROGRAMS = YES BuildFlavour = quick-llvm This build will fail with a error along the lines of, dll-split: internal error: invalid closure, info=0x402ec0 (GHC version 7.7.20131212 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug After some poking around with the help of Peter Wortmann, it seems clear that this is due to a subtle difference in how LLVM emits function symbols. While the NCG emits these symbols with `.type @object`, LLVM emits `.type @function`. It appears that the `.type` annotation guides the linker in choosing the relocation mechanism to use for the symbol. While `@object` symbols use the Global Offset Table, `@function` symbols are relocated through the Procedure Linking Table, a table of trampoline calls which are fixed up at runtime. This means that static references to functions end up pointing not to the object itself (and its info table) but instead to some linker-generated assembly. When the garbage collector attempts to examine the info table of one of these references, it finds nonsense and fails. # A solution Peter demonstrated that manually modifying the assembler produced by llc, passing this through GHC's mangler, and assembling the result yields a functional binary. As far as I can tell, LLVM's intermediate language doesn't expose any way to force a function to `.type @object`. Unfortunately this means that, at least for now, the only fix is to augment the mangler with logic to perform this transform. I've done this in my `llvm-dynamic` branch[1] (in addition to finding a bug in the `rewriteInstructions` function used by AVX rewriting). This branch compiles on my x86_64 machine to produce what appears to be a functional compiler. Unfortunately installation issues (which I'll describe shortly in a new thread) prevent me from verifying this. I'm currently waiting for a build on my ARM box but assuming this fix works this means that GHC could (finally) have first-class, stable ARM support. Comments? Cheers, - Ben [1] https://github.com/bgamari/ghc/tree/llvm-dynamic

3 6