1. 20 Jun, 2019 1 commit
    • John Ericson's avatar
      Move 'Platform' to ghc-boot · bff2f24b
      John Ericson authored
      ghc-pkg needs to be aware of platforms so it can figure out which
      subdire within the user package db to use. This is admittedly
      roundabout, but maybe Cabal could use the same notion of a platform as
      GHC to good affect too.
      bff2f24b
  2. 14 Jun, 2019 1 commit
    • Ben Gamari's avatar
      Maintain separate flags for C++ compiler invocations · 7bc5d6c6
      Ben Gamari authored
      Previously we would pass flags intended for the C compiler to the C++
      compiler (see #16738). This would cause, for instance, `-std=gnu99` to
      be passed to the C++ compiler, causing spurious test failures. Fix this
      by maintaining a separate set of flags for C++ compilation invocations.
      7bc5d6c6
  3. 01 Jun, 2019 1 commit
    • Ryan Scott's avatar
      Fix space leaks in dynLoadObjs (#16708) · 76e58890
      Ryan Scott authored
      When running the test suite on a GHC built with the `quick` build
      flavour, `-fghci-leak-check` noticed some space leaks. Careful
      investigation led to `Linker.dynLoadObjs` being the culprit.
      Pattern-matching on `PeristentLinkerState` and a dash of `$!` were
      sufficient to fix the issue. (ht to mpickering for his suggestions,
      which were crucial to discovering a fix)
      
      Fixes #16708.
      76e58890
  4. 29 May, 2019 1 commit
    • John Ericson's avatar
      Inline `Settings` into `DynFlags` · bfccd832
      John Ericson authored
      After the previous commit, `Settings` is just a thin wrapper around
      other groups of settings. While `Settings` is used by GHC-the-executable
      to initalize `DynFlags`, in principle another consumer of
      GHC-the-library could initialize `DynFlags` a different way. It
      therefore doesn't make sense for `DynFlags` itself (library code) to
      separate the settings that typically come from `Settings` from the
      settings that typically don't.
      bfccd832
  5. 22 May, 2019 1 commit
  6. 15 Mar, 2019 1 commit
  7. 07 Jan, 2019 1 commit
    • Alec Theriault's avatar
      Check that libs found by GCC aren't folders · 6b5ec08a
      Alec Theriault authored
      Summary:
      We use 'gcc -B<base-location> --print-file-name mylib.a' as a way of
      checking if 'gcc' can discover 'mylib.a' at the given location. However,
      this can break down if there is a folder caller 'mylib.a' that 'gcc' can
      discover. We can guard against this by explicitly checking that the path
      returned by 'gcc' is a file.
      
      This may seem like a far-fetched scenario, but since
      3d17f1f1, we look for libraries without
      any prefix or suffix (ie. 'extra-libraries: softfloat', we look for just
      'softfloat' as well as 'softloat.a', 'softfloat.dll.a', etc.) which means
      that there might actusally be a folder of that name in one of the base
      locations.
      
      Reviewers: Phyx, bgamari, hvr, angerman
      
      Reviewed By: Phyx, angerman
      
      Subscribers: angerman, rwbarton, carter
      
      GHC Trac Issues: #16063
      
      Differential Revision: https://phabricator.haskell.org/D5462
      6b5ec08a
  8. 17 Dec, 2018 1 commit
    • Zejun Wu's avatar
      Merge sections in profiling .a to .p_o and use it whenever it exists · de56a67a
      Zejun Wu authored
      Summary:
      We do this for vanilla way already.
      Let's also merge sections for profiling way and use it instead of the .a
      library when it exists.
      
      Test Plan:
      ```
       $ inplace/bin/ghc-stage2 --interactive -prof -fexternal-interpreter
       GHCi, version 8.7.20180921: http://www.haskell.org/ghc/  :? for help
       Prelude> pid <- System.Posix.Process.getProcessID
       Prelude> maps <- readFile $ "/proc/" ++ show pid ++ "/maps"
       Prelude> pid
       3807346
       Prelude> putStrLn $ unlines $ take 20 $ lines maps
       00400000-02103000 r-xp 00000000 00:1a 199277344
       /data/users/watashi/ghc/inplace/lib/bin/ghc-iserv-prof
       02104000-02106000 r--p 01d03000 00:1a 199277344
       /data/users/watashi/ghc/inplace/lib/bin/ghc-iserv-prof
       02106000-02417000 rw-p 01d05000 00:1a 199277344
       /data/users/watashi/ghc/inplace/lib/bin/ghc-iserv-prof
       02417000-0280a000 rw-p 00000000 00:00 0
       [heap]
       40098000-400b0000 rwxp 000d2000 00:1a 199276023
       /data/users/watashi/ghc/libraries/bytestring/dist-install/build/HSbytestring-0.10.8.2.p_o
       400b7000-400d8000 rwxp 00000000 00:00 0
       401d1000-401d2000 rwxp 000e9000 00:1a 199276023
       /data/users/watashi/ghc/libraries/bytestring/dist-install/build/HSbytestring-0.10.8.2.p_o
       40415000-40419000 rwxp 0000b000 00:1a 199275165
       /data/users/watashi/ghc/libraries/deepseq/dist-install/build/HSdeepseq-1.4.4.0.p_o
       404f8000-40526000 rwxp 000af000 00:1a 199274234
       /data/users/watashi/ghc/libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.3.p_o
      ```
      
      Reviewers: simonmar, bgamari, austin, hvr
      
      Reviewed By: simonmar
      
      Subscribers: rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5169
      de56a67a
  9. 11 Dec, 2018 1 commit
    • awson's avatar
      RTS linker: don't crash early when not finding extra-libraries · 21339c9f
      awson authored
      Allow GHCi to not crash when no assumed DLL is found in the standard
      location.  E.g. when loading the package built "dyn" way, we may well
      have the package's DLL around, and it's the system linker which loads
      necessary dependencies.
      
      Why does this (partially) fix #11042? It's because we often (and when
      having packages built `dyn` way -- almost always) don't need to load
      anything recorded in the `extra-libraries` stanza, since if the package
      DLL exists, GHCi linker simply calls the system linker (via `dlopen`/
      `LoadLibrary` APIs) to load it and doesn't bother to load package
      prelinked object file (if any) or package static library.
      
      Thus, all "regular" (with no fancy low-level package content
      manipulation) packages built "dyn" way should be OK after this fix.
      
      Reviewers: hvr, bgamari, int-index
      
      Reviewed By: bgamari, int-index
      
      Subscribers: Phyx, int-index, rwbarton, carter
      
      GHC Trac Issues: #11042
      
      Differential Revision: https://phabricator.haskell.org/D5170
      21339c9f
  10. 06 Aug, 2018 1 commit
    • Moritz Angermann's avatar
      Stop the linker panic · 4fc6524a
      Moritz Angermann authored
      If we fail to initialize the liker properly, we still set the
      `initLinkerDone`. In fact we even set that prior to actually
      initializing the linker. However if the linker initialization fails, we
      the `Done` state is still true. As such we run into the `Dynamic Linker
      not initialised` error. Which while technically corret is confusing as
      it pulls the attation away from the real issue.
      
      This change puts the Done state into an MVar, and as such ensureing
      that all parallel access needs to wait for the linker to be actually
      initialized, or try to re-initilize if it fails.
      
      Reviewers: bgamari, RyanGlScott, simonmar, hvr
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #9868, #10355, #13137, #13607, #13531
      
      Differential Revision: https://phabricator.haskell.org/D5012
      4fc6524a
  11. 01 Aug, 2018 1 commit
    • Moritz Angermann's avatar
      linker: Nub rpaths · b803c406
      Moritz Angermann authored
      When compiling and linking files in `ghci`, we keep adding rpath
      arguments to the linker command invoation.  If those are identical we
      should `nub` them out.  Otherwise we not only risk overflowing the
      argument limit, but also embed huge amounts of identical rpath values
      into the dynamic library, eventually leading to the overflow of the load
      command size limit, due to the number of rpath entries alone.
      
      A further improvement could be to pass `-Xlinker -dead_strip_dylibs`;
      that however might be stipping too aggressively, and potentially lead to
      missing symbols?
      
      For the time being I suggest to only do the nubbing and if need be to
      provide -Wl,-dead_strip_dylibs when invoking ghci.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, hvr
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15446
      
      Differential Revision: https://phabricator.haskell.org/D5021
      b803c406
  12. 16 Jul, 2018 1 commit
    • Simon Marlow's avatar
      Fix space leaks · 71f6b18b
      Simon Marlow authored
      Summary:
      All these were detected by -fghci-leak-check when GHC was
      compiled *without* optimisation (e.g. using the "quick" build flavour).
      
      Unfortunately I don't know of a good way to keep this working.  I'd like
      to just disable the -fghci-leak-check flag when the compiler is built
      without optimisation, but it doesn't look like we have an easy way to do
      that. And even if we could, it would be fragile anyway,
      
      Test Plan: `cd testsuite/tests/ghci; make`
      
      Reviewers: bgamari, hvr, erikd, tdammers
      
      Subscribers: tdammers, rwbarton, thomie, carter
      
      GHC Trac Issues: #15246
      
      Differential Revision: https://phabricator.haskell.org/D4872
      71f6b18b
  13. 13 Apr, 2018 1 commit
    • Ryan Scott's avatar
      Fix #9438 by converting a panic to an error message · 7613a812
      Ryan Scott authored
      Previously, GHC was quite eager to panic whenever it was fed
      an archive file when `DYNAMIC_GHC_PROGRAMS=YES`. This ought to be an
      explicit error message instead, so this patch accomplishes just that.
      
      Test Plan: make test TEST=T14708
      
      Reviewers: Phyx, hvr, bgamari
      
      Reviewed By: Phyx
      
      Subscribers: thomie, carter
      
      GHC Trac Issues: #9438, #14708, #15032
      
      Differential Revision: https://phabricator.haskell.org/D4589
      7613a812
  14. 26 Jan, 2018 1 commit
    • Ömer Sinan Ağacan's avatar
      Linker: ignore empty paths in addEnvPaths · cacba075
      Ömer Sinan Ağacan authored
      Previously `splitEnv` worked like this:
      
          > splitEnv "foo:::bar::baz:"
          ["foo","","","bar","","baz",""]
      
      with this patch:
      
          > splitEnv working_dir "foo:::bar:baz:"
          ["foo",working_dir,working_dir"bar","baz",working_dir]
      
      This fixes #14695, where having a trailing `:` in the env variable
      caused ghci to pass empty `-B` parameter to `gcc`, which in turned
      caused the next parameter (`--print-file-name`) to be considered as the
      argument to `-B`. As a result ghci did not work.
      
      The `working_dir` argument is to have a similar behavior with POSIX:
      according to chapter 8.3 zero-length prefix means current working
      directory.
      
      Reviewers: hvr, bgamari, AndreasK, simonmar
      
      Reviewed By: bgamari, AndreasK, simonmar
      
      Subscribers: AndreasK, rwbarton, thomie, carter
      
      GHC Trac Issues: #14695
      
      Differential Revision: https://phabricator.haskell.org/D4330
      cacba075
  15. 15 Jan, 2018 2 commits
    • Ben Gamari's avatar
      Support LIBRARY_PATH and LD_LIBRARY_PATH in rts · 87917a59
      Ben Gamari authored
      `LIBRARY_PATH` is used to find libraries and other link artifacts while
      `LD_LIBRARY_PATH` is used to find shared libraries by the loader.
      
      Due to an implementation detail on Windows, using `LIBRARY_PATH` will
      automatically add the path of any library found to the loader's path.
      
      So in that case `LD_LIBRARY_PATH` won't be needed.
      
      Test Plan:
      ./validate along with T14611 which has been made Windows only
      due to linux using the system linker/loader by default. So I feel a
      testcase there is unwarranted as the support is indirect via glibc.
      
      Reviewers: hvr, bgamari, erikd, simonmar, RyanGlScott
      
      Reviewed By: RyanGlScott
      
      Subscribers: RyanGlScott, rwbarton, thomie, carter
      
      GHC Trac Issues: #14611
      
      Differential Revision: https://phabricator.haskell.org/D4275
      87917a59
    • Tamar Christina's avatar
      Tweak link order slightly to prefer user shared libs before system ones. · 3d17f1f1
      Tamar Christina authored
      We currently always prefer shared libraries before import libraries and
      static libraries. This is because they're faster to load. The problem is
      when shared library are installed in the Windows directory. These would
      supersede any user specified ones.
      
      This is bad because e.g. Windows now ships icuuc, but an old version.
      If you try to use -licuuc then it would pick the Windows one instead of
      your user specified one.
      
      This patch slighly tweaks the ordering so user paths get prefered.
      
      Test Plan: ./validate
      
      Reviewers: RyanGlScott, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14456
      
      Differential Revision: https://phabricator.haskell.org/D4274
      3d17f1f1
  16. 03 Oct, 2017 1 commit
    • Tamar Christina's avatar
      Optimize linker by minimizing calls to tryGCC to avoid fork/exec overhead. · 8d647450
      Tamar Christina authored
      On Windows process creations are fairly expensive. As such calling them in
      what's essentially a hot loop is also fairly expensive.
      
      Each time we make a call to `tryGCC` the following fork/exec/wait happen
      
      ```
      gcc -> realgcc -> cc1
      ```
      
      This is very problematic, because according to the profiler about 20% of the
      time is spent on just process creation and spin time.
      
      The goal of the patch is to mitigate this by asking GCC once for it's search
      directories, caching these (because it's very hard to change these at all
      after the process started since GCC's base dirs don't change unless with
      extra supplied `-B` flags.).
      
      We also do the same for the `findSysDll` function, since this computes
      the search path every time by registery accesses etc.
      
      These changes and D3909 drop GHC on Windows startup time from 2-3s to 0.5s.
      
      The remaining issue is a 1.5s wait lock on `CONIN$` which can be addressed
      with the new I/O manager code. But this makes GHCi as responsive on Windows as
      GHC 7.8 was.
      
      Test Plan: ./validate
      
      Reviewers: austin, hvr, bgamari, erikd
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3910
      8d647450
  17. 19 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      compiler: introduce custom "GhcPrelude" Prelude · f63bc730
      Herbert Valerio Riedel authored
      This switches the compiler/ component to get compiled with
      -XNoImplicitPrelude and a `import GhcPrelude` is inserted in all
      modules.
      
      This is motivated by the upcoming "Prelude" re-export of
      `Semigroup((<>))` which would cause lots of name clashes in every
      modulewhich imports also `Outputable`
      
      Reviewers: austin, goldfire, bgamari, alanz, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D3989
      f63bc730
  18. 01 Aug, 2017 1 commit
    • Ryan Scott's avatar
      Drop GHC 7.10 compatibility · c13720c8
      Ryan Scott authored
      GHC 8.2.1 is out, so now GHC's support window only extends back to GHC
      8.0. This means we can delete gobs of code that was only used for GHC
      7.10 support. Hooray!
      
      Test Plan: ./validate
      
      Reviewers: hvr, bgamari, austin, goldfire, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: Phyx, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3781
      c13720c8
  19. 22 Jul, 2017 1 commit
    • Bartosz Nitka's avatar
      Avoid linear lookup in unload_wkr in the Linker · c1d96906
      Bartosz Nitka authored
      I've encountered an issue with following
      reproduction steps:
      * `:load` a large number of modules (~2000)
      * compile a BCO that depends on many other BCOs from many other modules
      * `:reload`
      * try to compile anything, even `1` works
      
      Before this patch the last step takes ~5s.
      It takes 80ms after.
      
      Test Plan: harbormaster
      
      Reviewers: simonmar, austin, hvr, bgamari
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3770
      c1d96906
  20. 08 Jun, 2017 1 commit
    • duog's avatar
      Refactor temp files cleanup · 3ee3822c
      duog authored
      Remove filesToNotIntermediateClean from DynFlags, create a data type
      FilesToClean, and change filesToClean in DynFlags to be a FilesToClean.
      
      Modify SysTools.newTempName and the Temporary constructor of
      PipelineMonad.PipelineOutput to take a TempFileLifetime, which specifies
      whether a temp file should live until the end of GhcMonad.withSession,
      or until the next time cleanIntermediateTempFiles is called.
      
      These changes allow the cleaning of intermediate files in GhcMake to be
      much more efficient.
      
      HscTypes.hptObjs is removed as it is no longer used.
      
      A new performance test T13701 is added, which passes both with and
      without -keep-tmp-files.  The test fails by 25% without the patch, and
      passes when -keep-tmp-files is added.
      
      Note that there are still at two hotspots caused by
      algorithms quadratic in the number of modules, however neither of them
      allocate. They are:
      
      * DriverPipeline.compileOne'.needsLinker
      * GhcMake.getModLoop
      
      DriverPipeline.compileOne'.needsLinker is changed slightly to improve
      the situation.
      
      I don't like adding these Types to DynFlags, but they need to be seen by
      Dynflags, SysTools and PipelineMonad. The alternative seems to be to
      create a new module.
      
      Reviewers: austin, hvr, bgamari, dfeuer, niteria, simonmar, erikd
      
      Reviewed By: simonmar
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13701
      
      Differential Revision: https://phabricator.haskell.org/D3620
      3ee3822c
  21. 01 Apr, 2017 1 commit
    • Simon Marlow's avatar
      askCc should be using the linker, not the compiler · 30828799
      Simon Marlow authored
      When GHCi tries to find a shared lib, it calls "gcc --print-file-name"
      to ask gcc where to find it.  But since we're looking for libraries,
      we're really using the linker here, not the C compiler, so we should be
      respecting the values of -pgml and -optl rather than -pgmc and -optc.
      
      Test Plan: validate
      
      Reviewers: bgamari, niteria, austin, hvr, erikd
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3393
      30828799
  22. 24 Mar, 2017 1 commit
  23. 15 Mar, 2017 1 commit
    • Ben Gamari's avatar
      Introduce putLogMsg · 086b514b
      Ben Gamari authored
      This factors out the repetition of (log_action dflags dflags) and will
      hopefully allow us to someday better abstract log output.
      
      Test Plan: Validate
      
      Reviewers: austin, hvr, goldfire
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3334
      086b514b
  24. 06 Mar, 2017 1 commit
    • Tamar Christina's avatar
      Add GCC bin folder to search path. · 016b10c5
      Tamar Christina authored
      D3155 added pthread by default to GHCi.  However this was only tested
      using something running in an msys2 shell. As it turns out it's been
      picking up pthread in the environment and not the inplace gcc.
      
      This results in an error when using ghci outside of msys2.
      
      Test Plan: start cmd, start ghc-stage2 --interactive
      
      Reviewers: austin, hvr, bgamari, dfeuer
      
      Reviewed By: dfeuer
      
      Subscribers: dfeuer, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3279
      016b10c5
  25. 02 Mar, 2017 1 commit
    • Tamar Christina's avatar
      Extend Windows runtime loader libsearch · f56fc7f7
      Tamar Christina authored
      This adds `.obj` extension to the list of valid
      object file (we really shouldn't be using extensions
      but instead trying to read the file and see if the header
      makes sense.). Microsoft compilers use .obj instead of .o
      for object files.
      
      This also adds support to finding static archives when the
      "lib" prefix is already in the filename. e.g. `-llibfoo` to
      find `libfoo.a`. This is inline with binutils.
      
      Test Plan: ./validate
      
      Reviewers: simonmar, erikd, bgamari, hvr, austin
      
      Reviewed By: bgamari
      
      Subscribers: RyanGlScott, thomie, #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D3082
      f56fc7f7
  26. 26 Feb, 2017 1 commit
    • Tamar Christina's avatar
      Load `pthreads` by default on Windows · be3f4362
      Tamar Christina authored
      The GCC Bindists that we use compile with `pthread` enabled by default.
      This means that on every link the dll is passed as a dependency by the
      driver. Lots of packages depend on it but the runtime linker doesn't
      provide it by default making compiled code work but not interpreted.
      
      Following D3028 `pthreads` would be provided by default ONLY when linked
      dynamicly, which we don't support yet (See D2592). Until this is the
      case we need to manually provide `libpthreads`.
      
      Test Plan: ./validate
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D3155
      be3f4362
  27. 03 Feb, 2017 1 commit
    • Sylvain Henry's avatar
      Ditch static flags · bbd3c399
      Sylvain Henry authored
      This patch converts the 4 lasting static flags (read from the command
      line and unsafely stored in immutable global variables) into dynamic
      flags. Most use cases have been converted into reading them from a DynFlags.
      
      In cases for which we don't have easy access to a DynFlags, we read from
      'unsafeGlobalDynFlags' that is set at the beginning of each 'runGhc'.
      It's not perfect (not thread-safe) but it is still better as we can
      set/unset these 4 flags before each run when using GHC API.
      
      Updates haddock submodule.
      
      Rebased and finished by: bgamari
      
      Test Plan: validate
      
      Reviewers: goldfire, erikd, hvr, austin, simonmar, bgamari
      
      Reviewed By: simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2839
      
      GHC Trac Issues: #8440
      bbd3c399
  28. 21 Jan, 2017 1 commit
    • niteria's avatar
      Always use -Xlinker for -rpath · f9ccad23
      niteria authored
      Currently we use `-Wl` which takes a list of
      comma-separated options. Unfortunately that
      breaks when you use it with `-rpath` and
      a path that has commas in them.
      Buck, the build system, produces paths with
      commas in them.
      
      `-Xlinker` doesn't have this disadvantage
      and as far as I can tell is supported by
      both `gcc` and `clang`. Anecdotally `nvcc`
      supports `-Xlinker`, but not `-Wl`.
      
      Test Plan: ./validate, harbourmaster
      
      Reviewers: nomeata, simonmar, austin, bgamari, hvr
      
      Reviewed By: simonmar, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2971
      f9ccad23
  29. 15 Jan, 2017 1 commit
    • Tamar Christina's avatar
      Fix abort and import lib search on Windows · 331f88d0
      Tamar Christina authored
      Summary:
      Apparently `sysErrorBelch` doesn't terminate the program anymore making
      previously unreachable code now execute. If a dll is not found the error
      message we return needs to be a heap value.
      
      Secondly also allow the pattern `lib<name>` to be allowed for finding an
      import library with the name `lib<name>.dll.a`.
      
      Test Plan: ./validate, new tests T13082_good and T13082_fail
      
      Reviewers: austin, RyanGlScott, hvr, erikd, simonmar, bgamari
      
      Reviewed By: RyanGlScott, bgamari
      
      Subscribers: thomie, #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D2941
      
      GHC Trac Issues: #13082
      331f88d0
  30. 13 Jan, 2017 1 commit
  31. 20 Dec, 2016 1 commit
  32. 19 Dec, 2016 1 commit
  33. 18 Dec, 2016 1 commit
  34. 11 Dec, 2016 1 commit
    • Moritz Angermann's avatar
      Make globals use sharedCAF · c3c70244
      Moritz Angermann authored
      Summary:
      The use of globals is quite painful when multiple rts are loaded, e.g.
      when plugins are loaded, which bring in a second rts. The sharedCAF
      appraoch was employed for the FastStringTable; I've taken the libery
      to extend this to the other globals I could find.
      
      This is a reboot of D2575, that should hopefully not exhibit the same
      windows build issues.
      
      Reviewers: Phyx, simonmar, goldfire, bgamari, austin, hvr, erikd
      
      Reviewed By: Phyx, simonmar, bgamari
      
      Subscribers: mpickering, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2773
      c3c70244
  35. 30 Nov, 2016 1 commit
  36. 29 Nov, 2016 1 commit
    • Moritz Angermann's avatar
      Make globals use sharedCAF · 6f7ed1e5
      Moritz Angermann authored
      The use of globals is quite painful when multiple rts are loaded, e.g.
      when plugins are loaded, which bring in a second rts. The sharedCAF
      appraoch was employed for the FastStringTable; I've taken the libery
      to extend this to the other globals I could find.
      
      Reviewers: rwbarton, simonmar, austin, hvr, erikd, bgamari
      
      Reviewed By: simonmar, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2575
      6f7ed1e5
  37. 06 Nov, 2016 1 commit
    • Tamar Christina's avatar
      Some minor linker cleanups. · 1964d869
      Tamar Christina authored
      Summary:
      Just some cleanups to some oddities I've noticed
      while investigating a linker issue.
      
      Particularly the dll name returned by `findSysDll`
      was decorated. So foo.dll is returned. We make it
      `foo.dll.dll` and later drop one `.dll` when passed to
      `addDll` which expects it without extension, but still
      tries the name *as is* which is why it worked.
      
      This should be slightly faster, since we don't try 4 loads
      before we succeed.
      
      Test Plan: ./validate
      
      Reviewers: austin, hvr, erikd, simonmar, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D2680
      1964d869
  38. 31 Oct, 2016 1 commit
    • Tamar Christina's avatar
      Align GHCi's library search order more closely with LDs · 795be0ea
      Tamar Christina authored
      Summary:
      Given a static library and an import library in the same folder. e.g.
      
      ```
      libfoo.a
      libfoo.dll.a
      ```
      
      running `ghci -lfoo` we should prefer the import library `libfoo.dll.a`
      over `libfoo.a` because we prefer having to just load the DLL.
      And not having to do any linking.
      
      This also more closely emulated the behaviour of LD, which has a search order of
      
      ```
      libxxx.dll.a
      xxx.dll.a
      libxxx.a
      cygxxx.dll (*)
      libxxx.dll
      xxx.dll
      ```
      
      Test Plan: ./validate
      
      Reviewers: RyanGlScott, austin, hvr, bgamari, erikd, simonmar
      
      Reviewed By: RyanGlScott
      
      Subscribers: thomie, #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D2651
      
      GHC Trac Issues: #12771
      795be0ea
  39. 22 Oct, 2016 1 commit
    • Duncan Coutts's avatar
      Add and use a new dynamic-library-dirs field in the ghc-pkg info · f41a8a36
      Duncan Coutts authored
      Summary:
      Build systems / package managers want to be able to control the file
      layout of installed libraries. In general they may want/need to be able
      to put the static libraries and dynamic libraries in different places.
      The ghc-pkg library regisrtation needs to be able to handle this.
      
      This is already possible in principle by listing both a static lib dir
      and a dynamic lib dir in the library-dirs field (indeed some previous
      versions of Cabal did this for shared libs on ELF platforms).
      
      The downside of listing both dirs is twofold. There is a lack of
      precision, if we're not careful with naming then we could end up
      picking up the wrong library. The more immediate problem however is
      that if we list both directories then both directories get included
      into the ELF and Mach-O shared object runtime search paths. On ELF this
      merely slows down loading of shared libs (affecting prog startup time).
      On the latest OSX versions this provokes a much more serious problem:
      that there is a rather low limit on the total size of the section
      containing the runtime search path (and lib names and related) and thus
      listing any unnecessary directories wastes the limited space.
      
      So the solution in this patch is fairly straightforward: split the
      static and dynamic library search paths in the ghc-pkg db and its use
      within ghc. This is a traditional solution: pkg-config has the same
      static / dynamic split (though it describes in in terms of private and
      public, but it translates into different behaviour for static and
      dynamic linking).
      
      Indeed it would make perfect sense to also have a static/dynamic split
      for the list of the libraries to use i.e. to have dynamic variants of
      the hs-libraries and extra-libraries fields. These are not immediately
      required so this patch does not add it, but it is a reasonable
      direction to follow.
      
      To handle compatibility, if the new dynamic-library-dirs field is not
      specified then its value is taken from the library-dirs field.
      
      Contains Cabal submodule update.
      
      Test Plan:
      Run ./validate
      
      Get christiaanb and carter to test it on OSX Sierra, in combination
      with Cabal/cabal-install changes to the default file layout for
      libraries.
      
      Reviewers: carter, austin, hvr, christiaanb, bgamari
      
      Reviewed By: christiaanb, bgamari
      
      Subscribers: ezyang, Phyx, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2611
      
      GHC Trac Issues: #12479
      f41a8a36