1. 08 Jun, 2017 1 commit
    • Moritz Angermann's avatar
      Check target libtool · cd8f4b99
      Moritz Angermann authored
      This will qualify the libtool with the target, e.g.
      arch-vendor-os-libtool, instead of simply using libtool.
      Reviewers: austin, hvr, bgamari
      Reviewed By: bgamari
      Subscribers: Ericson2314, ryantrinkle, rwbarton, thomie, erikd
      Differential Revision: https://phabricator.haskell.org/D3617
  2. 02 Jun, 2017 1 commit
  3. 01 Jun, 2017 1 commit
  4. 23 May, 2017 1 commit
  5. 12 May, 2017 1 commit
  6. 11 May, 2017 3 commits
    • Moritz Angermann's avatar
      Pass LLVMTarget (identical to --target) · 1345c7cc
      Moritz Angermann authored
      Sometimes it might be of interest to
      have access to the raw target value when calling
      subcommands (e.g. llvm tools with --target), as
      such we forward the specified (or inferred)
      --target for later consumption.
      Reviewers: austin, hvr, bgamari
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie, erikd
      Differential Revision: https://phabricator.haskell.org/D3559
    • Moritz Angermann's avatar
      Drop custom apple handling · 6ef6e7c6
      Moritz Angermann authored
      We know that *-apple-* is leading_underscores, and .dylib.
      It is also better to test for TargetVendor being apple, rather than
      relying on targetOS, which could be macOS, iOS, tvOS, watchOS,
      or any other glorious name apple could come up with.
      Reviewers: austin, hvr, bgamari
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie, erikd
      Differential Revision: https://phabricator.haskell.org/D3557
    • Moritz Angermann's avatar
      Do not hardcode the specific linker to use · 5ddb307e
      Moritz Angermann authored
      This should be handled appropriately by a wrapper script around the compiler,
      if one wants to insist on the specific linker to be used.  Otherwise this
      breaks if the used compiler fails to understand this directive.
      I believe that using a specific linker should be part of the compilers
      toolchain, we delegate to and not hardcoded here in ghc.
      Reviewers: dfeuer, erikd, hvr, austin, rwbarton, bgamari
      Reviewed By: bgamari
      Subscribers: snowleopard, davean, dfeuer, thomie, erikd
      Differential Revision: https://phabricator.haskell.org/D3351
  7. 08 May, 2017 1 commit
    • Moritz Angermann's avatar
      Fix Raspberry Pi · dc3b4af6
      Moritz Angermann authored
      This is two fold:
      - We did not catch all ARM_ARCH_6 defines. Specifically not `6K` and
        `6KZ`, which is what llvm seems to use these days for
        `arm-none-linux-gnueabihf` (e.g. the triple that's used for raspbian
        as well). Without it, ghc assums we want to compile against some armv7
        system, which raspbian is not (it is armv6 for maximum compatibility
        across the pi family, compromising on using armv7 and up features).
      - We stop forcing the -m and -arch flags on macOS. This is troublesome,
        as compiling for a 32bit system (e.g. raspberry pi, on a x86_64 macOS
        system results in the `-m64` flag being passed to to clang as well,
        which in turn figures out that you likely want 64bit, and rewrites
        your taret from `arm-none-linux-gnueabihf` to
        `aarch64-none-linux-gnueabihf`, which is definetly not what you want.
      Reviewers: austin, hvr, bgamari
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie, erikd
      Differential Revision: https://phabricator.haskell.org/D3546
  8. 25 Apr, 2017 2 commits
  9. 23 Apr, 2017 1 commit
  10. 17 Apr, 2017 1 commit
    • Sergei Trofimovich's avatar
      aclocal.m4: respect user's --with-ar= choice · 79848f18
      Sergei Trofimovich authored
      'FP_PROG_AR' macro has a minor bug: it ignores
      already existing value stored in '$fp_prog_ar'.
      I've noticed it when tried to built UNREG ghc using thin LTO:
        $ ./configure --enable-unregisterised \
                      --with-nm=gcc-nm \
                      --with-ar=gcc-ar \
                      --with-ranlib=gcc-ranlib \
      ./configure refused to use 'gcc-ar' (LTO-aware variant of 'ar')
      and kept using 'ar'.
      '$fp_prog_ar' is initialized (in a complex manner) in 'configure.ac' as:
          FP_ARG_WITH_PATH_GNU_PROG([AR], [ar], [ar])
      The change keeps that value.
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
  11. 29 Mar, 2017 2 commits
  12. 23 Jan, 2017 1 commit
  13. 20 Jan, 2017 1 commit
  14. 17 Dec, 2016 1 commit
  15. 14 Nov, 2016 1 commit
  16. 11 Nov, 2016 2 commits
    • Ben Gamari's avatar
      Pass -no-pie to GCC · d421a7e2
      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
    • Ben Gamari's avatar
      Revert "Pass -no-pie to GCC" · 60bb9d1c
      Ben Gamari authored
      This reverts commit bae4a55b.
      This will be superceded by D2693.
  17. 10 Nov, 2016 1 commit
    • Ben Gamari's avatar
      Pass -no-pie to GCC · bae4a55b
      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).
      Test Plan: Validate
      Reviewers: hvr, austin
      Subscribers: rwbarton, thomie, erikd
      Differential Revision: https://phabricator.haskell.org/D2691
      GHC Trac Issues: #12759
  18. 22 Aug, 2016 1 commit
    • kgardas's avatar
      pass -z wxneeded or -Wl,-zwxneeded for linking on OpenBSD · f9aa996f
      kgardas authored
      This patch fixes issue with abort in GHCi on OpenBSD current
      as of Aug 12 2016. The OpenBSD is more and more strict about usage
      of writable and executable memory. Programs/applications which
      requires such functionality need to be linked with -z wxneeded linker
      flag and need to be run from the file-system mounted with wxallowed
      mount option. If either of those options in not met, then problematic
      program/application usually fail on some mmap/mprotect call which fail.
      Reviewers: bgamari, austin, hvr
      Subscribers: thomie, erikd
      Differential Revision: https://phabricator.haskell.org/D2454
  19. 05 Jul, 2016 1 commit
    • Moritz Angermann's avatar
      Adds x86_64-apple-darwin14 target. · f560a03c
      Moritz Angermann authored
      x86_64-apple-darwin14, is the target for the 64bit simulator.
      Ideally, we'd have (i386|armv7|arm64|x64_86)-apple-ios, yet,
      many #ifdefs depend on `darwin`, notably libffi. Hence, this only adds
      x86_64-apple-darwin14 as a target. This also updates the comment to
      add the `-S` flag, and dump the output to stdout; and adjusts the
      `datalayout` and `triple` values, as obtained through the method
      mentioned in the comment.
      Reviewers: hvr, erikd, austin, bgamari, simonmar
      Reviewed By: simonmar
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2378
  20. 09 Jun, 2016 1 commit
    • Tamar Christina's avatar
      Remove special casing of Windows in generic files · 48385cb2
      Tamar Christina authored
      Remove some Windows specific code from the .m4 files
      and have configure figure it out.
      Unfortunately touchy can't be removed since there
      is no mingw build of coreutils. Only msys builds
      which would give us a dependency on the msys runtime.
      Reviewers: hvr, austin, thomie, bgamari
      Reviewed By: thomie, bgamari
      Subscribers: thomie, erikd, #ghc_windows_task_force
      Differential Revision: https://phabricator.haskell.org/D2248
  21. 24 May, 2016 1 commit
  22. 18 Apr, 2016 1 commit
  23. 16 Apr, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Rework CC/CC_STAGE0 handling in `configure.ac` · 865602e0
      Herbert Valerio Riedel authored
      Rather than using the non-standard/idiomatic `--with-{gcc,clang}=...`
      scheme use the `CC=...` style scheme.
      The basic idea is to have Autoconf's CC/CFLAG/CPPFLAG apply to
      stage{1,2,3}, while having a separate _STAGE0 set of env-vars
      denote the bootstrap-toolchain flags/programs.
      This should be simpler, less confusing, and somewhat more in line with
      Autoconf's idioms (allowing us to reuse more of Autoconf rather than
      (re)inventing our own confusing non-standard m4 macros to do stuff that
      Autoconf could almost do already for us)
      Morever, expose CC_STAGE0 as a so-called "precious" variable.
      So now we can better control which bootstrapping gcc is used
      (by default the one used by the stage0 ghc, unless CC_STAGE0 is
      Some influential environment variables:
        CC_STAGE0   C compiler command (bootstrap)
        CC          C compiler command
        CFLAGS      C compiler flags
      Use these variables to override the choices made by `configure' or to
      help it to find libraries and programs with nonstandard names/locations.
      Test Plan: I've tested that cross-compiling with
      `--target=powerpc-linux-gnu` still works, and tried a few variants of
      settting `CC=` and `CC_STAGE0=`; `./validate` passed as well
      Reviewers: erikd, austin, bgamari, simonmar
      Reviewed By: simonmar
      Subscribers: Phyx, thomie
      Differential Revision: https://phabricator.haskell.org/D2078
  24. 28 Mar, 2016 4 commits
    • Herbert Valerio Riedel's avatar
      Autoconf: detect and set CFLAGS/CPPFLAGS needed for C99 mode · afc48f89
      Herbert Valerio Riedel authored
      This is the first phase of addressing #11757 which aims to make C99
      support a base-line requirement for GHC and clean up the code-base to
      use C99 facilities when sensible.
      This patch exploits the logic/heuristic used by `AC_PROG_CC_C99` to
      determine the flags needed in case the C compiler isn't able to compile
      C99 code in its current mode. We can't use `AC_PROG_CC_C99` directly
      though because GHC's build-system expects CC to contain a filename
      without any flags, while `AC_PROG_CC_C99` would e.g. result in
      `CC="gcc -std=gnu99"`. Morever, we support different `CC`s for
      stage0/1/2, so we need a version of `AC_PROG_CC_C99` for which we can
      specify the `CC`/`CFLAGS` variables to operate on. This is what
      `FP_SET_CFLAGS_C99` does.
      Note that Clang has been defaulting to C99+ for a long time, while GCC 5
      defaults to C99+ as well. So this has mostly an affect on older GCCs
      versions prior to 5.0 and possibly compilers other than GCC/Clang (which
      are not officially supported for building GHC anyway).
      Reviewers: kgardas, erikd, bgamari, austin
      Reviewed By: erikd
      Differential Revision: https://phabricator.haskell.org/D2045
    • Herbert Valerio Riedel's avatar
      Drop Xcode 4.1 hack and fix ignored CC var issue · ffc802e8
      Herbert Valerio Riedel authored
      Xcode 4.1 was released back in 2011 for Mac OSX 10.6/10.7.
      However, OSX 10.7 reached EOL sometime around the end of 2014.
      So this `--with-gcc-4.2` hack shouldn't be needed anymore.
      Moreover, this patch changes ./configure to honor the CC env-var
      again (and thus fix #11231) while giving `--with-gcc=...` a higher
      priority over `CC=...`.
      So the following 3 invocations are equivalent now:
        CC=... ./configure
        ./configure CC=...
        ./configure --with-gcc=...
      Since `--with-{gcc,clang}=...` is a misnomer (as is made apparent by
      `--with-gcc=clang` or `--with-clang=gcc`), this would give us a neutral
      and idiomatic way to tell ./configure which C compiler to use.
      Moreover, `./configure --help` says at the end of its output:
        Some influential environment variables:
          CC		C compiler command
          CFLAGS	C compiler flags
          LDFLAGS	linker flags, e.g. -L<lib dir> if you have libraries in a
      		nonstandard directory <lib dir>
          LIBS	libraries to pass to the linker, e.g. -l<library>
          CPPFLAGS	(Objective) C/C++ preprocessor flags, e.g. -I<include dir> if
      		you have headers in a nonstandard directory <include dir>
          CPP		C preprocessor
        Use these variables to override the choices made by `configure' or to help
        it to find libraries and programs with nonstandard names/locations.
      Consequently, by honoring CC=... (rather than ignoring it) we increase
      consistency and reduce user confusion. Ideally, CC=... would become the
      recommended way to set the C compiler, and `--with-{clang,gcc}=...`
      would be demoted to legacy aliases.
      Reviewed By: erikd, bgamari
      Differential Revision: https://phabricator.haskell.org/D2046
    • Herbert Valerio Riedel's avatar
      Scrap DEC OSF/1 support · f911358b
      Herbert Valerio Riedel authored
      DEC OSF/1 (aka Tru64 UNIX) has been discontinued a few years ago already[1].
      This removes the undoubtedly bitrotten support for `OSOsf3 :: OS` from GHC's
      Support for `ArchAlpha :: Arch` may be removed at some later point, as there
      may still be users out there running a more or less recent Linux/alpha
      distribution on their more-than-a-decade old Alpha hardware...
       [1]: https://en.wikipedia.org/wiki/Tru64_UNIX
    • Herbert Valerio Riedel's avatar
      Scrap IRIX support · 0bca3f3a
      Herbert Valerio Riedel authored
      Long time ago, IRIX was way ahead of its time in the last century with
      its SMP capabilities of scaling up to 1024 processors and other features
      such as XFS or OpenGL that originated in IRIX and live on to this day in
      other operating systems.
      However, IRIX's last software update was in 2006 and support ended
      around 2013 according to [1], so it's considered an extinct platform by
      now. So this commit message is effectively an obituary for GHC's IRIX
      R.I.P. IRIX
       [1]: https://en.wikipedia.org/wiki/IRIX
  25. 24 Mar, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Add NCG support for AIX/ppc32 · df26b955
      Herbert Valerio Riedel authored
      This extends the previous work to revive the unregisterised GHC build
      for AIX/ppc32. Strictly speaking, AIX runs on POWER4 (and later)
      hardware, but the PPC32 instructions implemented in the PPC NCG
      represent a compatible subset of the POWER4 ISA.
      IBM AIX follows the PowerOpen ABI (and shares many similiarites with the
      Linux PPC64 ELF V1 NCG backend) but uses the rather limited XCOFF
      format (compared to ELF).
      This doesn't support dynamic libraries yet.
      A major limiting factor is that the AIX assembler does not support the
      `@ha`/`@l` relocation types nor the ha16()/lo16() functions Darwin's
      assembler supports. Therefore we need to avoid emitting those. In case
      of numeric literals we simply compute the functions ourselves, while for
      labels we have to use local TOCs and hope everything fits into a 16bit
      offset (for ppc32 this gives us at most 16384 entries per TOC section,
      which is enough to compile GHC).
      Another issue is that XCOFF doesn't seem to have a relocation type for
      label-differences, and therefore the label-differences placed into
      tables-next-to-code can't be relocated, but the linker may rearrange
      different sections, so we need to place all read-only sections into the
      same `.text[PR]` section to workaround this.
      Finally, the PowerOpen ABI distinguishes between function-descriptors
      and actualy entry-point addresses. For AIX we need to be specific when
      emitting assembler code whether we want the address of the function
      descriptor `printf`) or for the entry-point (`.printf`). So we let the
      asm pretty-printer prefix a dot to all emitted subroutine
      calls (i.e. `BL`) on AIX only. For now, STG routines' entry-point labels
      are not prefixed by a label and don't have any associated
      Reviewers: austin, trommler, erikd, bgamari
      Reviewed By: trommler, erikd, bgamari
      Differential Revision: https://phabricator.haskell.org/D2019
  26. 25 Jan, 2016 1 commit
    • Ben Gamari's avatar
      Ensure that we don't produce code for pre-ARMv7 without barriers · 9fe7d20e
      Ben Gamari authored
      We are unable to produce load/store barriers for pre-ARMv7 targets.
      Phab:D894 added dummy cases to SMP.h for these barriers to prevent the
      build from failing under the assumption that there are no SMP-capable
      devices of this vintage. However, #10433 points out that it is more
      correct to simply set NOSMP for such targets.
      Tested By: rwbarton
      Test Plan: Validate
      Reviewers: erikd, rwbarton, austin
      Reviewed By: rwbarton
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D1704
      GHC Trac Issues: #10433
  27. 08 Jan, 2016 1 commit
    • thomie's avatar
      Build system: fix `pwd` issues on Windows · f7b45c31
      thomie authored
      Some parts of the build system require that paths are what msys2 calls
      "mixed style":
        * forwards slashes
        * absolute paths starting with a drive letter followed by a colon
          (e.g. "C:")
      The removal of ghc-pwd in 4c56ad36 changed $(TOP) from mixed style to
      unix style, resulting in a broken Windows build for some.
      Differential Revision: https://phabricator.haskell.org/D1752
  28. 04 Jan, 2016 1 commit
    • thomie's avatar
      Build system: delete ghc-pwd · 4c56ad36
      thomie authored
      On Windows, with msys2, `pwd` works (as can be seen by the use of `pwd`
      that slipped into the validate script), so there is really no need for
      `ghc-pwd` anymore.
      Test Plan: try it
      Reviewers: austin, bgamari, Phyx
      Reviewed By: Phyx
      Subscribers: Phyx, erikd
      Differential Revision: https://phabricator.haskell.org/D1731
  29. 28 Dec, 2015 2 commits
    • Herbert Valerio Riedel's avatar
      Make git-committer inferred version-date TZ-invariant · bab51097
      Herbert Valerio Riedel authored
      The existing code suffers from the issue of converting the
      committer date to localtime, thereby resulting in varying
      inferred dates for the same commit-hash depending on the currently
      set local timezone.
      In order to have a universally unique mapping between commit-hashes and
      their snapshot-version-date it's better to convert to the date expressed
      in a fixed timezone like e.g. UTC.
      Sadly, `git` doesn't seem to provide a way to directly format dates the
      way we need it, so we shell out to `perl` for this.
      Reviewers: austin, thomie, erikd, bgamari
      Differential Revision: https://phabricator.haskell.org/D1711
    • 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
  30. 20 Dec, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      aclocal.m4: Fix llc/opt detection code · f7bd37ed
      Herbert Valerio Riedel authored
      Currently if llc/opt is missing, we get
        checking for llc-3.7... no
        checking for llc... no
        checking  is version 3.7... ./configure[7417]: --version:  not found
        checking for opt-3.7... no
        checking for opt... no
        checking  is version 3.7... ./configure[7664]: --version:  not found
        checking for llc... no
        checking for opt... no
      With this fix, the version is queried iff `llc`/`opt` has been detected
      at all, thereby avoiding the disturbing `--version: not found` error
      Reviewed By: thomie
      Differential Revision: https://phabricator.haskell.org/D1674
  31. 19 Dec, 2015 1 commit