1. 04 Jan, 2017 1 commit
  2. 11 Nov, 2016 2 commits
    • Ben Gamari's avatar
      Pass -no-pie to GCC · fefe02c0
      Ben Gamari authored
      Certain distributions (e.g. Debian and Ubuntu) have enabled PIE be
      default in their GCC packaging. This breaks our abuse of GCC as a linker
      which requires that we pass -Wl,-r, which is incompatible with
      PIE (since the former implies that we are generating a relocatable
      object file and the latter an executable).
      
      This is a second attempt at D2691. This attempt constrasts with D2691 in that
      it preserves the "does gcc support -no-pie" flag in settings, allowing this to
      be reconfigured by `configure` during installation of a binary distribution.
      Thanks for @rwbarton for drawing attention to this issue.
      
      Test Plan: Validate
      
      Reviewers: austin, hvr, erikd
      
      Reviewed By: erikd
      
      Subscribers: thomie, rwbarton, erikd
      
      Differential Revision: https://phabricator.haskell.org/D2693
      
      GHC Trac Issues: #12759
      fefe02c0
    • Ben Gamari's avatar
      Revert "Pass --no-pie to GCC" · 3da461d9
      Ben Gamari authored
      This reverts commit 60c299a2. We really
      want to be able to change this in the binary distribution `configure`
      script. Trying again in D2693.
      3da461d9
  3. 10 Nov, 2016 1 commit
    • Ben Gamari's avatar
      Pass --no-pie to GCC · 60c299a2
      Ben Gamari authored
      Certain distributions (e.g. Debian and Ubuntu) have enabled PIE be
      default in their GCC packaging. This breaks our abuse of GCC as a linker
      which requires that we pass -Wl,-r, which is incompatible with
      PIE (since the former implies that we are generating a relocatable
      object file and the latter an executable).
      60c299a2
  4. 07 Nov, 2016 2 commits
  5. 19 Sep, 2016 2 commits
    • Sergei Trofimovich's avatar
      configure.ac: fix --host= handling · b2050299
      Sergei Trofimovich authored
      The following command fails as:
          $ ./configure --prefix=/usr \
              --build=x86_64-pc-linux-gnu \
              --host=x86_64-pc-linux-gnu \
              --target=x86_64-pc-linux-gnu
          configure: error:
          You've selected:
      
            BUILD:  x86_64-unknown-linux
            HOST:   x86_64-unknown-linux
            TARGET: x86_64-unknown-linux
      
          BUILD must equal HOST;
      
      18f06878
      
       changed native
      configure $build/$host/$target checks to ghc-mangled ones,
      but not completely.
      Signed-off-by: default avatarSergei Trofimovich <siarheit@google.com>
      
      Reviewers: rwbarton, erikd, austin, hvr, bgamari, Phyx
      
      Reviewed By: Phyx
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2508
      
      GHC Trac Issues: #12487
      
      (cherry picked from commit 0cc3931b)
      b2050299
    • Tamar Christina's avatar
      Fix configure detection. · 682518d4
      Tamar Christina authored
      Summary:
      GHC's configure script seems to normalize the values returned from config.guess.
      So for Windows it turns x86_64-pc-mingw64 into x86_64-unknown-mingw32.
      These mangled names are stored in the values $BuildPlatform, $HostPlatform
      and $TargetPlatform.
      
      However further down the file when the comparison is done between the stage0
      compiler and the host the normalized versions are not used.
      So when normalization actually changes the triple this check will fail.
      
      Not sure why it's worked for all this time.. Nor if this is the right fix?
      Does it still work for cross compiling correctly?
      
      Test Plan: ./configure
      
      Reviewers: hvr, austin, thomie, bgamari, erikd
      
      Reviewed By: erikd
      
      Subscribers: erikd, #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D2452
      
      GHC Trac Issues: #12487
      
      (cherry picked from commit 18f06878)
      682518d4
  6. 21 May, 2016 1 commit
  7. 16 May, 2016 1 commit
    • Ben Gamari's avatar
      Move Extension type to ghc-boot-th · c0147941
      Ben Gamari authored
      This creates a new package, `ghc-boot-th`, to contain the `Extension`
      type, which now lives in `GHC.LanguageExtension.Type`. This ensures that
      the transitive dependency set of the `template-haskell` package remains
      minimal.
      
      The `GHC.LanguageExtensions.Type` module is also re-exported by
      `ghc-boot`, which provides an orphan `binary` instance as well.
      
      Test Plan: Validate
      
      Reviewers: goldfire, thomie, hvr, austin
      
      Reviewed By: thomie
      
      Subscribers: RyanGlScott, thomie, erikd, ezyang
      
      Differential Revision: https://phabricator.haskell.org/D2224
      
      (cherry picked from commit eed820b6)
      c0147941
  8. 11 May, 2016 1 commit
  9. 21 Apr, 2016 1 commit
  10. 17 Apr, 2016 1 commit
  11. 10 Apr, 2016 1 commit
    • Tamar Christina's avatar
      Change runtime linker to perform lazy loading of symbols/sections · 068d9273
      Tamar Christina authored
      The Runtime Linker is currently eagerly loading all object files on all
      platforms which do not use the system linker for `GHCi`.
      
      The problem with this approach is that it requires all symbols to be
      found.  Even those of functions never used/called. This makes the number
      of libraries required to link things like `mingwex` quite high.
      
      To work around this the `rts` was relying on a trick. It itself was
      compiled with `MingW64-w`'s `GCC`. So it was already linked against
      `mingwex`.  As such, it re-exported the symbols from itself.
      
      While this worked it made it impossible to link against `mingwex` in
      user libraries. And with this means no `C99` code could ever run in
      `GHCi` on Windows without having the required symbols re-exported from
      the rts.
      
      Consequently this rules out a large number of packages on Windows.
      SDL2, HMatrix etc.
      
      After talking with @rwbarton I have taken the approach of loading entire
      object files when a symbol is needed instead of doing the dependency
      tracking on a per symbol basis. This is a lot less fragile and a lot
      less complicated to implement.
      
      The changes come down to the following steps:
      
      1) modify the linker to and introduce a new state for ObjectCode:
         `Needed`.  A Needed object is one that is required for the linking to
         succeed.  The initial set consists of all Object files passed as
         arguments to the link.
      
      2) Change `ObjectCode`'s to be indexed but not initialized or resolved.
         This means we know where we would load the symbols,
         but haven't actually done so.
      
      3) Mark any `ObjectCode` belonging to `.o` passed as argument
         as required: ObjectState `NEEDED`.
      
      4) During `Resolve` object calls, mark all `ObjectCode`
         containing the required symbols as `NEEDED`
      
      5) During `lookupSymbol` lookups, (which is called from `linkExpr`
         and `linkDecl` in `GHCI.hs`) is the symbol is in a not-yet-loaded
         `ObjectCode` then load the `ObjectCode` on demand and return the
         address of the symbol. Otherwise produce an unresolved symbols error
         as expected.
      
      6) On `unloadObj` we then change the state of the object and remove
         it's symbols from the `reqSymHash` table so it can be reloaded.
      
      This change affects all platforms and OSes which use the runtime linker.
      It seems there are no real perf tests for `GHCi`, but performance
      shouldn't be impacted much. We gain a lot of time not loading all `obj`
      files, and we lose some time in `lookupSymbol` when we're finding
      sections that have to be loaded. The actual finding itself is O(1)
      (Assuming the hashtnl is perfect)
      
      It also consumes slighly more memory as instead of storing just the
      address of a symbol I also store some other information, like if the
      symbol is weak or not.
      
      This change will break any packages relying on renamed POSIX functions
      that were re-named and re-exported by the rts. Any packages following
      the proper naming for functions as found on MSDN will work fine.
      
      Test Plan: ./validate on all platforms which use the Runtime linker.
      
      Reviewers: thomie, rwbarton, simonmar, erikd, bgamari, austin, hvr
      
      Reviewed By: erikd
      
      Subscribers: kgardas, gridaphobe, RyanGlScott, simonmar,
                   rwbarton, #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D1805
      
      GHC Trac Issues: #11223
      
      (cherry picked from commit 90538d86)
      068d9273
  12. 28 Mar, 2016 1 commit
  13. 11 Mar, 2016 2 commits
  14. 19 Jan, 2016 1 commit
    • Edward Z. Yang's avatar
      Switch from -this-package-key to -this-unit-id. · 9cebc245
      Edward Z. Yang authored
      
      
      A small cosmetic change, but we have to do a bit of work to
      actually support it:
      
          - Cabal submodule update, so that Cabal passes us
            -this-unit-id when we ask for it.  This includes
            a Cabal renaming to be consistent with Unit ID, which
            makes ghc-pkg a bit more scrutable.
      
          - Build system is updated to use -this-unit-id rather than
            -this-package-key, to avoid deprecation warnings.  Needs
            a version test so I resurrected the old test we had
            (sorry rwbarton!)
      
          - I've *undeprecated* -package-name, so that we are in the same
            state as GHC 7.10, since the "correct" flag will have only
            entered circulation in GHC 8.0.
      
          - I removed -package-key.  Since we didn't deprecate -package-id
            I think this should not cause any problems for users; they
            can just change their code to use -package-id.
      
          - The package database is indexed by UNIT IDs, not component IDs.
            I updated the naming here.
      
          - I dropped the signatures field from ExposedModule; nothing
            was using it, and instantiatedWith from the package database
            field.
      
          - ghc-pkg was updated to use unit ID nomenclature, I removed
            the -package-key flags but I decided not to add any new flags
            for now.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: 23Skidoo, thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D1780
      
      (cherry picked from commit 240ddd7c)
      9cebc245
  15. 15 Jan, 2016 1 commit
  16. 11 Jan, 2016 1 commit
  17. 10 Jan, 2016 1 commit
  18. 30 Dec, 2015 2 commits
  19. 28 Dec, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Synchronise ghci-package version with ghc-package · 01299ca8
      Herbert Valerio Riedel authored
      In order to simplify the task, the version munging logic has
      been radically simplified:
      
      Previously, in cases where the version contained dates as version components,
      the build-system would munge the version of the stage1 ghc package before
      registering the `ghc` package.
      
      However, this hack was already questionable at the time of its introduction
      (c.f. 7b45c46c).
      Simplifying the build-systems by avoiding such hacks may also help the
      shaking-up-ghc effort.
      
      So now we simply munge directly via the `.cabal` files, which gives a simpler
      picture, as now every stage is munged the same. Munging is only active when
      the first patch-level version component is a date. So stable snapshots and release
      candidates are unaffacted (as those have the date in the second patch-level
      version component)
      
      Reviewers: simonmar, bgamari, austin, thomie, ezyang
      
      Reviewed By: bgamari, thomie, ezyang
      
      Differential Revision: https://phabricator.haskell.org/D1673
      01299ca8
  20. 18 Dec, 2015 2 commits
  21. 17 Dec, 2015 1 commit
  22. 06 Dec, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Tweak use of AC_USE_SYSTEM_EXTENSIONS · 8b422142
      Herbert Valerio Riedel authored
      This makes sure that `AC_USE_SYSTEM_EXTENSIONS` (which
      implies `AC_PROG_CC`) is called after the
      `AC_ARG_WITH([cc],,)` invocation, so that the proper
      CC setting is in scope. Otherwise this can break cross-compilation.
      
      This also needs to pull in a submodule update for `unix`
      
      This is a follow-up commit to
      7af29da0
      which hopefully fixes #11168
      8b422142
  23. 04 Dec, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Use Autoconf's AC_USE_SYSTEM_EXTENSIONS · 7af29da0
      Herbert Valerio Riedel authored
      This takes care of setting feature test macros (i.e. let Autoconf decide when
      those can be set safely) to allow subsequent Autoconf tests to better detect
      available OS features.
      
      This also includes a submodule update of unix which enables the use of
      `AC_USE_SYSTEM_EXTENSIONS` in there as well.
      
      Specifically, this takes care of setting `_GNU_SOURCE` (which allows to remove
      two occurences where it's set manually) and `_ALL_SOURCE` (which fixes issues
      on AIX).
      
      See also
      
        https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Posix-Variants.html
      
      for details.
      
      At some point we may want to reconsider the purpose of "rts/PosixSource.h" and
      rely more on Autoconf instead.
      7af29da0
  24. 23 Nov, 2015 1 commit
  25. 19 Nov, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Make `derivedConstants` more crosscompile-friendly · 65d7ff06
      Herbert Valerio Riedel authored
      `derivedConstants` currently uses `System.Info.os` for decisions (which
      doesn't necessarily reflect the build-target), as well as hardcoding
      "/usr/bin/objdump" for openbsd.
      
      This patch auto-detects `objdump` similiar to how `nm` is detected via
      Autoconf as well as passing the target-os into `derivedConstants` via
      commandline.
      
      Reviewers: austin, kgardas, erikd, bgamari
      
      Reviewed By: kgardas, erikd, bgamari
      
      Subscribers: kgardas, thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D1499
      65d7ff06
  26. 18 Nov, 2015 1 commit
  27. 01 Nov, 2015 2 commits
  28. 31 Oct, 2015 2 commits
    • kgardas's avatar
      disable large address space on OpenBSD · bc7cc256
      kgardas authored
      Summary:
      This patch disables large address space on OpenBSD. The motivation
      for this is that OpenBSD does not support MAP_NORESERVE. The flag is supported
      only for source code compatibility reasons but is otherwise completely ignored
      by the OS and its mmap syscall.
      
      Reviewers: austin, bgamari
      
      Subscribers: thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D1411
      bc7cc256
    • Tamar Christina's avatar
      Fix documentation build on windows · 6bef55c6
      Tamar Christina authored
      Summary:
      Fix building new Sphinx documenation on Windows in msys2 using Awson's patch on #11021.
      
      Install Sphinx using `pacman -S mingw-w64-$(uname -m)-python2-sphinx`
      
      Test Plan: Apply patch and ./validate
      
      Reviewers: thomie, bgamari, austin
      
      Reviewed By: thomie, bgamari
      
      Subscribers: erikd
      
      Differential Revision: https://phabricator.haskell.org/D1408
      
      GHC Trac Issues: #11021
      6bef55c6
  29. 30 Oct, 2015 1 commit
  30. 24 Oct, 2015 2 commits
    • Erik de Castro Lopo's avatar
      configure.ac: Fix autotool warnings · 798d2e2b
      Erik de Castro Lopo authored
      Test Plan: perl boot and check for warnings
      
      Reviewers: niteria, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1364
      798d2e2b
    • niteria's avatar
      Support more sphinx-build versions in configure script · 4e403403
      niteria authored
      `sphinx-build` on CentOS
      (`python-sphinx10-doc-1.0.8-1.el6.centos.noarch`) responds with this on
      `stderr`:
      ```
      $ sphinx-1.0-build --version
      Sphinx v1.0.8
      Usage: /usr/bin/sphinx-1.0-build [options] sourcedir outdir
      [filenames...]
      Options: -b <builder> -- builder to use; default is html
               -a        -- write all files; default is to only write new and
      changed files
      ...
      Modi:
      * without -a and without filenames, write new and changed files.
      * with -a, write all files.
      * with filenames, write these.
      ```
      
      This should make it work for the old and the new format.
      
      Test Plan:
      ```
      $ echo "Sphinx (sphinx-build) 1.0.1" | sed 's/Sphinx\(
      (sphinx-build)\)\? v\?\([0-9]\.[0-9]\.[0-9]\)/\2/'
      1.0.1
      $ echo "Sphinx v1.0.1" | sed 's/Sphinx\( (sphinx-build)\)\?
      v\?\([0-9]\.[0-9]\.[0-9]\)/\2/'
      1.0.1
      ```
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D1361
      4e403403
  31. 23 Oct, 2015 1 commit
    • Ben Gamari's avatar
      Verify minimum required version of sphinx-build · 7dae0743
      Ben Gamari authored
      CentOS 6.6 includes sphinx-build 0.6.6 which is woefully inadequate to
      build the users guide. In particular it fails as it lacks
      `sphinx.ext.extlinks`, which was introduced in 1.0.0. Looking at the
      changelog it appears that 1.0.0 ought to work.
      7dae0743