summaryrefslogtreecommitdiff
path: root/distrib
Commit message (Collapse)AuthorAgeFilesLines
* llvmGen: Accept range of LLVM versionsBen Gamari2021-03-171-3/+4
| | | | | | | Previously we would support only one LLVM major version. Here we generalize this to accept a range, taking this range to be LLVM 10 to 11, as 11 is necessary for Apple M1 support. We also accept 12, as that is what apple ships with BigSur on the M1.
* mkDocs: address shellcheck issuesAdam Sandberg Ericsson2020-12-221-4/+4
|
* mkDocs: fix extraction of Win32 docs from hadrian bindistAdam Sandberg Ericsson2020-12-221-2/+6
|
* mkDocs: support hadrian bindists #18973Adam Sandberg Ericsson2020-12-121-1/+3
|
* Refactor handling of object mergingBen Gamari2020-08-051-0/+1
| | | | | | | | | Previously to merge a set of object files we would invoke the linker as usual, adding -r to the command-line. However, this can result in non-sensical command-lines which causes lld to balk (#17962). To avoid this we introduce a new tool setting into GHC, -pgmlm, which is the linker which we use to merge object files.
* Replace ghcWithNativeCodeGen with a proper Backend datatypeSylvain Henry2020-07-222-2/+0
| | | | | | | | | | | | | | | | * Represent backends with a `Backend` datatype in GHC.Driver.Backend * Don't detect the default backend to use for the target platform at compile time in Hadrian/make but at runtime. It makes "Settings" simpler and it is a step toward making GHC multi-target. * The latter change also fixes hadrian which has not been updated to take into account that the NCG now supports AIX and PPC64 (cf df26b95559fd467abc0a3a4151127c95cb5011b9 and d3c1dda60d0ec07fc7f593bfd83ec9457dfa7984) * Also we don't treat iOS specifically anymore (cf cb4878ffd18a3c70f98bdbb413cd3c4d1f054e1f)
* Kill wORDS_BIGENDIAN and replace it with platformByteOrder (#17957)Sylvain Henry2020-04-011-0/+11
| | | | | | Metric Decrease: T13035 T1969
* Rework handling of win32 toolchain tarballsBen Gamari2020-02-141-6/+0
|
* configure: Find Python3 for testsuiteBen Gamari2020-01-071-0/+3
| | | | | In addition, we prefer the Mingw64 Python distribution on Windows due to #17483.
* Fix typos, via a Levenshtein-style correctorBrian Wignall2020-01-041-1/+1
|
* configure: Add --with-libdw-{includes,libraries} flagsBen Gamari2019-11-061-0/+4
| | | | Fixing #17255.
* distrib: Fix binary distribution installationBen Gamari2019-10-291-2/+4
| | | | | This had silently regressed due to 81860281 and the variable renaming performed in b55ee979, as noted in #17374.
* Make sure all boolean settings entries use `YES` / `NO`John Ericson2019-09-051-2/+2
| | | | | | | | | Some where using `True` / `False`, a legacy of when they were in `Config.hs`. See #16914 / d238d3062a9858 for a similar problem. Also clean up the configure variables names for consistency and clarity while we're at it. "Target" makes clear we are talking about outputted code, not where GHC itself runs.
* Don't package settings in bindistBen Gamari2019-07-141-2/+3
| | | | | | | | | | | | Since !712 the `settings` file is produced by the build system instead of autoconf. However, this introduced a subtle bug where we would fail to rebuild the `settings` file with what we have learned from the install-time `configure` invocation. Fix this by not packaging `settings` in the bindist tarball. The build system will take care of the rest. Also fix a bug where the value of `UseLibdw` was not being persisted to the install time `configure`.
* distrib/configure.ac.in: remove mention to 'settings', since settings.in is goneAlp Mestanogullari2019-05-211-1/+1
| | | | | | | | Otherwise, when `./configure`ing a GHC bindist, produced by either Make or Hadrian, we would try to generate the `settings` file from the `settings.in` template that we used to have around but which has been gone since d37d91e9. That commit generates the settings file using the build systems instead, but forgot to remove this mention to the `settings` file.
* Generate settings by make/hadrian instead of configureJohn Ericson2019-04-301-1/+1
| | | | This allows it to eventually become stage-specific
* Remove unused remilestoning scriptÖmer Sinan Ağacan2019-04-111-119/+0
|
* Clean up URLs to point to GitLabTakenobu Tani2019-04-011-1/+1
| | | | | | | | | | | | This moves URL references to old Trac to their corresponding GitLab counterparts. This patch does not update the submodule library, such as libraries/Cabal. See also !539, !606, !618 [ci skip]
* Update Wiki URLs to point to GitLabTakenobu Tani2019-03-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | This moves all URL references to Trac Wiki to their corresponding GitLab counterparts. This substitution is classified as follows: 1. Automated substitution using sed with Ben's mapping rule [1] Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy... New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy... 2. Manual substitution for URLs containing `#` index Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...#Zzz New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...#zzz 3. Manual substitution for strings starting with `Commentary` Old: Commentary/XxxYyy... New: commentary/xxx-yyy... See also !539 [1]: https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mapping.json
* Update Trac ticket URLs to point to GitLabRyan Scott2019-03-151-2/+2
| | | | | This moves all URL references to Trac tickets to their corresponding GitLab counterparts.
* Rip out perl dependencyBen Gamari2019-03-091-10/+0
| | | | | | The object splitter was the last major user of perl. There remain a few uses in nofib but we can just rely on the system's perl for this since it's not critical to the build.
* Rip out object splittingBen Gamari2019-03-052-2/+0
| | | | | | | | | | | | | | | The splitter is an evil Perl script that processes assembler code. Its job can be done better by the linker's --gc-sections flag. GHC passes this flag to the linker whenever -split-sections is passed on the command line. This is based on @DemiMarie's D2768. Fixes Trac #11315 Fixes Trac #9832 Fixes Trac #8964 Fixes Trac #8685 Fixes Trac #8629
* configure: Document CLANG, LLC, and OPT variablesBen Gamari2019-02-121-0/+2
|
* distrib/configure: Set RanlibCmdBen Gamari2018-11-231-0/+2
| | | | This fixes #15875.
* distrib: Remove mention of no-longer-existent make targetBen Gamari2018-10-031-3/+0
| | | | | | | | | | | | | | | Summary: `show-install-setup` used to be defined by `distrib/Makefile` which hasn't been used in a very long time and was removed from the tree in a1c008b30fc60a327afe098cf16bd14ca1e5e381. Reviewers: monoidal Reviewed By: monoidal Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5194
* Bump autoconf version bound to >= 2.69Ben Gamari2018-03-191-0/+3
| | | | | | | | | | Reviewers: hvr Subscribers: rwbarton, thomie, erikd, carter GHC Trac Issues: #14910 Differential Revision: https://phabricator.haskell.org/D4495
* configure: Various cleanupsJohn Ericson2018-01-151-28/+29
| | | | | | | | | | | | | | | | | Substitute RanlibCmd for consistency, and other configure cleanups that should have no effect The other commands are so substituted. Maybe we don't need ranlib at all, and the configure snippet can be removed all together, but that can always be done later. Reviewers: bgamari, hvr, angerman Reviewed By: bgamari, angerman Subscribers: rwbarton, thomie, erikd, carter Differential Revision: https://phabricator.haskell.org/D4286
* configure: Don't hard-code strip toolBen Gamari2017-09-251-0/+6
| | | | | | | | | | | | | | For reasons that I don't entirely understand we didn't previously detect `strip` using autoconf. This naturally broke during cross-compilation. How did this ever work? I have no idea. Test Plan: Try cross-compiling Reviewers: austin, hvr, angerman Subscribers: rwbarton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D4008
* get-win32-tarballs: Use correct `find`Ben Gamari2017-09-051-0/+6
| | | | | | | | | | | | | | | | | This fixes #12502 by using the `find` utility found by FP_PROG_FIND instead of the first one in PATH. Test Plan: Validate on Windows Reviewers: Phyx, austin, hvr Reviewed By: Phyx Subscribers: rwbarton, thomie, erikd GHC Trac Issues: #12502 Differential Revision: https://phabricator.haskell.org/D3907
* Preserve HaskellHaveRTSLinker in bindistBen Gamari2017-07-231-0/+3
| | | | | Otherwise you end up with ("target has RTS linker","@HaskellHaveRTSLinker@") in the installed settings file.
* distrib/configure: Carry FFI include/lib paths from source distributionBen Gamari2017-07-231-0/+7
| | | | | | | | | | | | | | | | | | | `FFILibDir` and `FFIIncludeDir` both show up in the `rts` library's package registration file. We therefore must define them or else we'll end up with spurious `@FFILibDir@` strings in the package registration. In principle I think we could also take these as arguments to the bindist configure but this seems simpler and I don't want to verify this at the moment. Test Plan: Build bindist while passing `--with-ffi-libraries=...` to source distribution configure then try to install and use bindist. Reviewers: austin, hvr Subscribers: rwbarton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D3774
* distrib/configure: Canonicalize triplesBen Gamari2017-07-201-0/+7
| | | | | | | | | | | | | | | | Previously we failed to do this, which meant that the bindist's configure would fail when passed --target (as you may need to do when installing an armv7 bindist on an aarch64 machine, for instance). Reviewers: hvr, erikd, austin Reviewed By: hvr Subscribers: rwbarton, thomie GHC Trac Issues: #13934 Differential Revision: https://phabricator.haskell.org/D3761
* distrib/configure: Fail if we can't detect machine's word sizeBen Gamari2017-07-121-3/+13
| | | | | | | | | | | | | | | | | | This is a sure sign that something is terribly wrong. We also now verify that the word size that the binary distribution expects matches the word size produced by the local target toolchain. Finally we rename WordSize to TargetWordSize, since non-host/target qualified quantities are terribly confusing. Reviewers: austin, hvr, Phyx Reviewed By: Phyx Subscribers: Phyx, rwbarton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D3711
* mkDocs: Don't install *.psBen Gamari2017-07-051-1/+1
| | | | We now longer produce PostScript output.
* Add -fuse-ld flag to CFLAGS during configureBen Gamari2017-07-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | The decisions made by configure later in the script may depend upon the linker used. Consequently, it is important that configure uses the same linker as GHC will eventually use. For instance, on Nix I found that a program requiring `libpthread` would link fine with only `-lrt` when linked with BFD ld. However, with gold we needed to explicitly provide the `-lpthread` dependency. Presumably the former would happily loaded any `NEEDED` libraries whereas the latter wants them explicitly given. Regardless, since `configure`'s `NEED_PTHREAD_LIB` check didn't use the `-fuse-ld` flag that GHC would eventually use, we inferred the wrong value, resulting in link errors later in the build. Test Plan: Validate Reviewers: austin, hvr Subscribers: rwbarton, thomie, erikd GHC Trac Issues: #13541 Differential Revision: https://phabricator.haskell.org/D3694
* configure: Coerce gcc to use $LD instead of system defaultBen Gamari2017-06-291-12/+13
| | | | | | | | | | | | | | | | | | | | | | | | The configure script will now try to coerce gcc to use the linker pointed to by $LD instead of the system default (typically bfd ld). Moreover, we now check for `ld.gold` and `ld.lld` before trying `ld`. The previous behavior can be reverted to by using the new --disable-ld-override flag. On my machine gold seems to trigger an apparent infelicity in constructor behavior, causing T5435_asm to fail. I've opened #13883 to record this issue and have accepted the questionable constructor ordering for the time being. Test Plan: Validate with `config_args='--enable-ld-override'` Reviewers: austin, hvr, simonmar Subscribers: duog, nh2, rwbarton, thomie, erikd, snowleopard GHC Trac Issues: #13541, #13810, #13883 Differential Revision: https://phabricator.haskell.org/D3449
* Do not hardcode the specific linker to useMoritz Angermann2017-05-111-1/+1
| | | | | | | | | | | | | | | | | 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
* configure: Kill off FP_ARG_WITH_*Ben Gamari2017-04-251-2/+2
| | | | | | | | | | | | | | | | | This replaces the --with-* configure flags with the usual autoconf environment variables, as suggested by #13583. Test Plan: Configure on various platforms Reviewers: hvr, trofi, thomie, austin Reviewed By: trofi Subscribers: rwbarton, erikd GHC Trac Issues: #13583 Differential Revision: https://phabricator.haskell.org/D3499
* Pass -no-pie to GCCBen Gamari2016-11-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Pass -no-pie to GCC"Ben Gamari2016-11-101-1/+0
| | | | | | This reverts commit bae4a55b1fb403f610b4b55a1b6fb3f03e9c2026. This will be superceded by D2693.
* Pass -no-pie to GCCBen Gamari2016-11-101-0/+1
| | | | | | | | | | | | | | | | | | 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
* distrib: Fix libdw bindist checkBen Gamari2016-09-051-11/+12
| | | | | | | | | | | | | | | | | As reported in #12555 this code was terribly broken. Sadly, Autoconf was none-the-wiser. Thanks to @rwbarton for pointing this out. Test Plan: Test with libdw version newer and older and 0.158 Reviewers: hvr, austin, rwbarton Reviewed By: rwbarton Subscribers: thomie, rwbarton, erikd Differential Revision: https://phabricator.haskell.org/D2510 GHC Trac Issues: #12555
* Build system: mention ghc version in bindist's `configure --help` docdirThomas Miedema2016-06-141-1/+1
| | | | | | | | | | | This is a follow up to a74a3846c84ad55de3deeed8b2401a2ed514b2e1 , which made the same change but for the toplevel configure.ac. Reviewed by: erikd Differential Revision: https://phabricator.haskell.org/D2330 GHC Trac Issues: #11659
* Fix detection and use of `USE_LIBDW`Erik de Castro Lopo2016-06-011-2/+2
| | | | | | | | | | | | Test Plan: Configure/build with and without --enable-libdw Reviewers: trofi, hvr, austin, simonmar, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2276
* Rework CC/CC_STAGE0 handling in `configure.ac`Herbert Valerio Riedel2016-04-161-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 overriden) ``` 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
* libdw: More precise version checkBen Gamari2016-04-161-2/+8
| | | | | | | | | | | | Test Plan: Try configure in an environment with older `libdw` Reviewers: hvr, austin Subscribers: thomie, erikd Differential Revision: https://phabricator.haskell.org/D2103 GHC Trac Issues: #11820
* Autoconf: detect and set CFLAGS/CPPFLAGS needed for C99 modeHerbert Valerio Riedel2016-03-281-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* mkDocs: Fix fallout from c5f4f95c64006a9fBen Gamari2016-02-071-1/+1
| | | | Fixes #11419
* mkDocs: Update for xzBen Gamari2016-02-071-3/+3
| | | | Fixes #11419.
* Build system: fix `pwd` issues on WindowsThomas Miedema2016-01-081-2/+3
| | | | | | | | | | | | | 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 4c56ad3 changed $(TOP) from mixed style to unix style, resulting in a broken Windows build for some. Differential Revision: https://phabricator.haskell.org/D1752
View Lorry Controller Status