summaryrefslogtreecommitdiff
path: root/configure.ac
Commit message (Collapse)AuthorAgeFilesLines
* Testsuite: Skip failing tests on PowerPC 64-bitPeter Trommler2016-12-271-0/+12
| | | | | | | | | | | | | | | | | | | The Power ISA says the result of a division by zero is undefined. So ignore stdout on PowerPC 64-bit systems. Disable ext-interp tests on 64-bit PowerPC. We don't have support for PowerPC 64-bit ELF in the RTS linker, which is needed for the external interpreter. Test Plan: ./validate Reviewers: austin, simonmar, hvr, erikd, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2782
* Switch to LLVM version 3.9Erik de Castro Lopo2016-11-181-1/+1
| | | | | | | | | | | | | Test Plan: Build and test on x86_64/linux (perf-llvm) and armhf/linux. Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: RyanGlScott, thomie Differential Revision: https://phabricator.haskell.org/D2719
* Pass autoconf triplets to sub-project configuresShea Levy2016-11-171-1/+5
| | | | | | | | | | | | Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie, erikd Differential Revision: https://phabricator.haskell.org/D2713 GHC Trac Issues: #12840
* Pass -no-pie to GCCBen Gamari2016-11-111-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | 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-3/+0
| | | | | | This reverts commit bae4a55b1fb403f610b4b55a1b6fb3f03e9c2026. This will be superceded by D2693.
* Pass -no-pie to GCCBen Gamari2016-11-101-0/+3
| | | | | | | | | | | | | | | | | | 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
* configure: Pass HC_OPTS_STAGEx to build systemBen Gamari2016-11-101-0/+4
| | | | | | | | | | Test Plan: Try `./configure HC_OPTS_STAGE0=-foobar` and watch it fail Reviewers: austin, hvr Subscribers: thomie, erikd Differential Revision: https://phabricator.haskell.org/D2674
* build system: Include CONF_LD_LINKER_OPTS in ALL_LD_OPTSBen Gamari2016-11-101-0/+5
| | | | | | | | | | | | | | | This ensures that artifacts built with build-prog see these options. Also spruce up comments. Test Plan: Carefully read it. Reviewers: austin, hvr, erikd Reviewed By: erikd Subscribers: thomie, erikd Differential Revision: https://phabricator.haskell.org/D2673
* rts: configure.ac should populate HAVE_LIBNUMA instead of USE_LIBNUMADarshan Kapashi2016-10-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Code in rts/ which deals with numa checks for `#if HAVE_LIBNUMA`, however this macro is not populated during `./configure`. https://phabricator.haskell.org/D2329 changed this code last and we instead set `USE_LIBNUMA` which fails to setup numa correctly. Test Plan: From main directory in ghc, ./configure && make clean && make boot && make cd nofib/parallel/queens ../../../inplace/bin/ghc-stage2 Main.hs -rtsopts -threaded ./Main 15 +RTS -N24 -s -A64m --numa This fails before this patch with Main: --numa: OS reports NUMA is not available After the fix, it works as expected. Run the validation script, ./validate (It fails with an error in `compiler/utils/Util.hs` saying `GHC.Stack.CallStack` not found, once I remove this 1 line from this file , the script works) Reviewers: hvr, austin, bgamari, erikd, simonmar Reviewed By: erikd, simonmar Subscribers: mpickering, thomie, erikd, niteria Differential Revision: https://phabricator.haskell.org/D2620 GHC Trac Issues: #12741
* configure.ac: Report Unregisterised settingErik de Castro Lopo2016-10-201-0/+1
| | | | | | | | | | | | | | | Showing the value of this configure option in the configure output can help debugging issues in build bots etc. Test Plan: N/A Reviewers: hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2616
* configure.ac: fix --host= handlingSergei Trofimovich2016-09-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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; 18f06878ed5d8cb0cf366a876f2bfea29647e5f0 changed native configure $build/$host/$target checks to ghc-mangled ones, but not completely. Signed-off-by: Sergei 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
* Darwin: Detect broken NM program at configure timeErik de Castro Lopo2016-08-161-0/+26
| | | | | | | | | | | | | | | | Some recent versions of XCode ship a broken version of `nm`. Detect this at configure time, and error out with a suggestion to rerun configure with a `--with-nm=...` argument. Test Plan: Test of Linux and OS X Reviewers: carter, hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2425
* Fix configure detection.Tamar Christina2016-08-141-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* configure.ac: Remove checks for bug 9439Erik de Castro Lopo2016-08-071-67/+0
| | | | | | | | | | | | | | | Bug #9439 only affects some ghc 7.8 versions of the compiler and since git HEAD no longer builds with ghc-7.8 we can drop this check. Test Plan: Works here! Reviewers: hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2427
* Switch to LLVM version 3.8Erik de Castro Lopo2016-07-071-1/+1
| | | | | | | | | | | | | | LLVM 3.8 was released a couple of months ago. Test Plan: Build and test on x86_64/linux (perf-llvm) and armhf/linux. Reviewers: austin, hvr, rwbarton, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2382
* rts: Fix NUMA when cross compilingErik de Castro Lopo2016-06-131-3/+6
| | | | | | | | | | | | | | | | | | | | | | | The NUMA code was enabled whenever numa.h and numaif.h are detected. Unfortunately, the hosts' header files were being detected even then cross compiling in the absence of a target libnuma. Fix that by relying on the the presence of libnuma instead of the presence of the header files. The test for libnuma does `AC_TRY_LINK` which will fail if the test program (compiled for the target) can't be linked against libnuma. Test Plan: Build on x86_64/linux and make sure NUMA works and cross compile to armhf/linux. Reviewers: austin, bgamari, hvr, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2329
* NUMA supportSimon Marlow2016-06-101-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The aim here is to reduce the number of remote memory accesses on systems with a NUMA memory architecture, typically multi-socket servers. Linux provides a NUMA API for doing two things: * Allocating memory local to a particular node * Binding a thread to a particular node When given the +RTS --numa flag, the runtime will * Determine the number of NUMA nodes (N) by querying the OS * Assign capabilities to nodes, so cap C is on node C%N * Bind worker threads on a capability to the correct node * Keep a separate free lists in the block layer for each node * Allocate the nursery for a capability from node-local memory * Allocate blocks in the GC from node-local memory For example, using nofib/parallel/queens on a 24-core 2-socket machine: ``` $ ./Main 15 +RTS -N24 -s -A64m Total time 173.960s ( 7.467s elapsed) $ ./Main 15 +RTS -N24 -s -A64m --numa Total time 150.836s ( 6.423s elapsed) ``` The biggest win here is expected to be allocating from node-local memory, so that means programs using a large -A value (as here). According to perf, on this program the number of remote memory accesses were reduced by more than 50% by using `--numa`. Test Plan: * validate * There's a new flag --debug-numa=<n> that pretends to do NUMA without actually making the OS calls, which is useful for testing the code on non-NUMA systems. * TODO: I need to add some unit tests Reviewers: erikd, austin, rwbarton, ezyang, bgamari, hvr, niteria Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2199
* Remove special casing of Windows in generic filesTamar Christina2016-06-091-8/+5
| | | | | | | | | | | | | | | | | | Summary: 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
* Fix detection and use of `USE_LIBDW`Erik de Castro Lopo2016-06-011-4/+12
| | | | | | | | | | | | 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
* Set `USE_MMAP` at configure timeErik de Castro Lopo2016-05-171-0/+28
| | | | | | | | | | | | | | | Summary: The `USE_MMAP` macro is used in the run time linker and was being set with some really ugly CPP hackery. Setting in the configure script is much neater. Reviewers: rwbarton, hvr, austin, simonmar, bgamari Reviewed By: hvr, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2223
* Move Extension type to ghc-boot-thBen Gamari2016-05-161-1/+1
| | | | | | | | | | | | | | | | | | | | 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
* Fix path to the new build system, now called Hadrian.Andrey Mokhov2016-04-281-3/+3
| | | | | | | | | | | | | | | | | | | Summary: The new Shake-based build system has been given a name -- Hadrian, and now lives in /hadrian directory. This fixes the path to the configuration file to be populated by the configure script. Test Plan: Run Hadrian build. Reviewers: thomie, bgamari, hvr, austin Reviewed By: austin Subscribers: erikd Differential Revision: https://phabricator.haskell.org/D2153
* Use stdint types to define SIZEOF and ALIGNMENT of INTx/WORDxTomas Carnecky2016-04-181-33/+23
| | | | | | | | | | | | | Saves us a CPP #if in MachDeps.h since we now can always rely on a 64-bit type being available. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie, erikd Differential Revision: https://phabricator.haskell.org/D2099
* Rework CC/CC_STAGE0 handling in `configure.ac`Herbert Valerio Riedel2016-04-161-8/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+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
* Change runtime linker to perform lazy loading of symbols/sectionsTamar Christina2016-04-111-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove obsolete --with-hc flag from ./configureHerbert Valerio Riedel2016-03-281-9/+0
| | | | | This was probably missed during the big build-system refactoring in 34cc75e1a62638f2833815746ebce0a9114dc26b
* 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
* Remove now obsolete LD_STAGE0 hackHerbert Valerio Riedel2016-03-271-3/+1
| | | | | | | This was introduced in 109a1e53287f50103e8a5b592275940b6e3dbb53 but isn't needed anymore because by now we're bootstrapping with GHC versions which already provide "ld command" in `ghc --info` (that field was added in GHC 7.8)
* Include version in AC_PACKAGE_TARNAMEBen Gamari2016-03-111-1/+1
| | | | | | | | | | | | | | | | | | `AC_PACKAGE_TARNAME` is used by autoconf to generate the default value of docdir, which we now set to include a version number (see #11354). This fixed #11659. Test Plan: `./configure --help`, validate Reviewers: austin, thomie, hvr, erikd Reviewed By: hvr, erikd Subscribers: erikd Differential Revision: https://phabricator.haskell.org/D1983 GHC Trac Issues: #11659
* rts/timer: use timerfd_* on Linux instead of alarm signalsSylvain HENRY2016-03-051-1/+1
| | | | | | | | | | | | Reviewers: erikd, simonmar, austin, bgamari Reviewed By: simonmar, bgamari Subscribers: hvr, thomie Differential Revision: https://phabricator.haskell.org/D1947 GHC Trac Issues: #10840
* Switch from -this-package-key to -this-unit-id.Edward Z. Yang2016-01-191-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Edward 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
* configure.ac: Export MAKECMD to build systemKarel Gardas2016-01-151-8/+19
| | | | | | | | | | Reviewers: austin, bgamari, thomie Reviewed By: thomie Subscribers: angerman, thomie, erikd Differential Revision: https://phabricator.haskell.org/D1775
* 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
* Build system: delete ghc-pwdThomas Miedema2016-01-041-4/+2
| | | | | | | | | | | | | | | | 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
* Simplify -fcmm-sink handling for Parser.hsHerbert Valerio Riedel2015-12-311-6/+0
| | | | | | As we're requiring GHC >= 7.10 now, the conditional handling introduced in 9e133b9dccec0553c6ec302d6ca0d3bc5eea06c4 for addressing #8182 can be made unconditional, and thus simplify the build-system a little bit.
* Remove ghc-7.8 `-package-name`-compat handlingHerbert Valerio Riedel2015-12-311-5/+0
| | | | | | This code was introduced in 66218d15b7c27a4a38992003bd761f60bae84b1f to use `-package-name` for GHC 7.8, whereas GHC 7.10 needs the new `-this-package-key` flag.
* Drop pre-AMP compatibility CPP conditionalsHerbert Valerio Riedel2015-12-311-2/+2
| | | | | | | | | | | | Since GHC 8.1/8.2 only needs to be bootstrap-able by GHC 7.10 and GHC 8.0 (and GHC 8.2), we can now finally drop all that pre-AMP compatibility CPP-mess for good! Reviewers: austin, goldfire, bgamari Subscribers: goldfire, thomie, erikd Differential Revision: https://phabricator.haskell.org/D1724
* Bump GHC HEAD's Version from 7.11 to 8.1ghc-8.1-startHerbert Valerio Riedel2015-12-301-1/+1
| | | | This updates the haddock submodule
* Synchronise ghci-package version with ghc-packageHerbert Valerio Riedel2015-12-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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. 7b45c46cbabe1288ea87bd9b94c57e010ed17e60). 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
* configure.ac: Rename build/ to shake-build/Ben Gamari2015-12-181-2/+2
| | | | Last naming change... I promise.
* configure.ac: Rename shake/ to build/Ben Gamari2015-12-181-2/+4
| | | | See https://github.com/snowleopard/shaking-up-ghc/pull/2
* Add Shake configuration to configure.acBen Gamari2015-12-171-0/+3
| | | | | | | | | | | | | The Shake build system requires that this file be generated by autoconf. Generate it if we find a shake tree. Reviewers: austin, hvr Reviewed By: hvr Subscribers: thomie, erikd Differential Revision: https://phabricator.haskell.org/D1638
* Tweak use of AC_USE_SYSTEM_EXTENSIONSHerbert Valerio Riedel2015-12-061-3/+3
| | | | | | | | | | | | | 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 7af29da05d2e5a5e311a5f73f20d0f232035973b which hopefully fixes #11168
* Use Autoconf's AC_USE_SYSTEM_EXTENSIONSHerbert Valerio Riedel2015-12-041-0/+3
| | | | | | | | | | | | | | | | | | | | | | 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.
* Rip out Papi configure checkBen Gamari2015-11-231-7/+0
|
* Make `derivedConstants` more crosscompile-friendlyHerbert Valerio Riedel2015-11-191-0/+8
| | | | | | | | | | | | | | | | | | `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
* rts: Kill PAPI supportBen Gamari2015-11-181-6/+0
| | | | | | | | | | | | | | | This hasn't been used for a very long time and will soon be superceded by perf_events support. Test Plan: validate Reviewers: austin, simonmar Reviewed By: austin, simonmar Subscribers: thomie, erikd Differential Revision: https://phabricator.haskell.org/D1493
* Change sphinx for documentation building on windows to the python3 versionTamar Christina2015-11-011-11/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Python 3 seems to have fixed the long standing codepage issue with python on Windows. To be able to reliably build the documentation we should use the Python 3 version of Sphinx. See `https://docs.python.org/dev/whatsnew/3.3.html#codecs` and `https://bugs.python.org/issue13216`. Sphinx also supports Python 3. Oddly enough `python3-sphinx` is registered as `sphinx-build.exe` instead of `sphinx-build3.exe`, so the changes in `configure.ac` can be reverted. install with `pacman -S mingw-w64-$(uname -m)-python3-sphinx` Test Plan: ./validate Reviewers: austin, thomie, bgamari Reviewed By: bgamari Subscribers: erikd Differential Revision: https://phabricator.haskell.org/D1417 GHC Trac Issues: #11021
* Enforce linkage with pthread library on OpenBSDKarel Gardas2015-11-011-0/+9
| | | | | | | | | | | | | | | | This patch enforces linkage with pthread library on OpenBSD. This is done in order to avoid linker errors when linking with libffi which requires POSIX threading but itself is not linked with libpthread directly. So client binaries (of libffi) needs to link against libpthread explicitly Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie, erikd Differential Revision: https://phabricator.haskell.org/D1410
View Lorry Controller Status