summaryrefslogtreecommitdiff
path: root/aclocal.m4
Commit message (Collapse)AuthorAgeFilesLines
...
* Drop special handling of iOS and AndroidMoritz Angermann2017-09-071-8/+2
| | | | | | | | | | | | | | | As far as GHC is concerned, iOS **is** Darwin, and Android **is** Linux. Depends on D3352 Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: Ericson2314, ryantrinkle, rwbarton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D3579
* Clean up opt and llcMoritz Angermann2017-09-061-0/+7
| | | | | | | | | | | | | | | | | | | | | The LLVM backend shells out to LLVMs `opt` and `llc` tools. This clean up introduces a shared data structure to carry the arguments we pass to each tool so that corresponding flags are next to each other. It drops the hard coded data layouts in favor of using `-mtriple` and have LLVM infer them. Furthermore we add `clang` as a proper tool, so we don't rely on assuming that `clang` is called `clang` on the `PATH` when using `clang` as the assembler. Finally this diff also changes the type of `optLevel` from `Int` to `Word`, as we do not have negative optimization levels. Reviewers: erikd, hvr, austin, rwbarton, bgamari, kavon Reviewed By: kavon Subscribers: michalt, Ericson2314, ryantrinkle, dfeuer, carter, simonpj, kavon, simonmar, thomie, erikd, snowleopard Differential Revision: https://phabricator.haskell.org/D3352
* Add gen-dll as replacement for dll-splitTamar Christina2017-08-291-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This tool can be used to generate dll's for any list of object files given to it. It will then repartition them automatically to fit within a dll and generates as many dll's as needed to do this. Cyclic dependencies between these generated dlls are handle automatically so there is no need to tell it how to partition. It is also a lot more general than `dll-split` as it is able to split any package not just `libGHC`. It also uses a trick using GNU style import libraries to hide the splitting from the rest of the pipeline. Which means come linking time you don't need to know which dll contains what symbol or how many split dlls were created. The import libraries are by default created with libtool. However since libtool is BFD based it is very slow. So if present and detected by configure the `genlib` tool from the msys2 project is used. This makes a difference of about ~45 minutes when compiling. To install `genlib` run `pacman -Sy mingw-w64-$(uname -m)-tools-git`. More detailed explaination of the process can be found here https://ghc.haskell.org/trac/ghc/wiki/WindowsDynamicLinking Test Plan: ./validate Reviewers: austin, hvr, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: snowleopard, rwbarton, thomie, erikd, #ghc_windows_task_force GHC Trac Issues: #5987 Differential Revision: https://phabricator.haskell.org/D3883
* configure: Ensure that user's LD setting is respectedBen Gamari2017-07-281-0/+1
| | | | This broke in the fix for #13541.
* Fix lld detection if both gold and lld are foundBen Gamari2017-07-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If you have ld.gold and ld.lld, then ld.gold will be selected by the detection logic. This patch prioritizes lld by changing the order. The rationale for checking lld first is that it's (right now) not part of, say, a default Linux distro installation and if it's available, it's very likely that it was installed explicitly and should be seen as a sign of preference. On FreeBSD LLVM is the (default) base toolchain and the changed order makes sense there as well, since ld.gold can be available in /usr/local via ports/pkg. I don't have access to macOS and can't say anything about their LLVM toolchain. At some point we could add a check for LD=ld.lld or LD=ld.gold as an optional override to explicitly select a linker. Since I cannot really remove gcc on Linux, this was the only way to configure GHC to use ld.lld. Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, erikd Tags: PHID-PROJ-5azim3sqhsf7wzvlvaag Differential Revision: https://phabricator.haskell.org/D3790
* configure: Cleanup ARM COPY bug test artifactsBen Gamari2017-07-181-1/+3
|
* Use correct section types syntax for architectureBen Gamari2017-07-111-1/+10
| | | | | | | | | | | | | | | | | | Previously GHC would always assume that section types began with `@` while producing assembly, which is not true. For instance, in ARM assembly syntax section types begin with `%`. This abstracts out section type pretty-printing and adjusts it to correctly account for the target architectures assembly flavor. Reviewers: austin, hvr, Phyx Reviewed By: Phyx Subscribers: Phyx, rwbarton, thomie, erikd GHC Trac Issues: #13937 Differential Revision: https://phabricator.haskell.org/D3712
* configure: Ensure that we don't set LD to unusable linkerBen Gamari2017-07-111-5/+7
| | | | | | | | | | | | | | | | | | | Previously if we found an unusable linker in PATH (e.g. ld.lld on OS X) we would notice the -fuse-ld=... was broken, but neglected to reset LD to a usable linker. This resulted in brokenness on OS X when lld is in PATH. Test Plan: Validate on OS X with lld in PATH Reviewers: austin, hvr, angerman Reviewed By: angerman Subscribers: rwbarton, thomie, erikd, angerman GHC Trac Issues: #13541 Differential Revision: https://phabricator.haskell.org/D3713
* aclocal.m4: allow arbitrary <vendor> string in toolchain tripletsSergei Trofimovich2017-07-081-2/+1
| | | | | | | | | | | | | | | | | | | | Canonical triplets have a form of <arch>-<vendor>-<os>[-<abi>] Checking for vendor is almost never correct as it's an arbitrary string. It's useful to have multiple "vendors" to denote otherwise the same (WRT <arch>, <os>, <abi>) target: --target=x86_64-pc-linux-gnu --target=x86_64-unknown-linux-gnu --target=x86_64-ghc80-linux-gnu --target=x86_64-ghchead-linux-gnu Do not fail unknown vendors. Only emit a warning. Ideally configure checks should never use "vendor". Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
* configure: Remove --with-curses-includes flagBen Gamari2017-07-031-5/+0
| | | | | | | | | | | terminfo no longer needs to be able to find the ncurses headers. See https://github.com/judah/terminfo/pull/22. Reviewers: austin, hvr Subscribers: rwbarton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D3688
* configure: Coerce gcc to use $LD instead of system defaultBen Gamari2017-06-291-46/+60
| | | | | | | | | | | | | | | | | | | | | | | | 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
* configure: Check for binutils #17166Ben Gamari2017-06-291-0/+59
| | | | | | | | | | | | | | | | | | | This bug affects bfd ld on ARMv7, causing ld to incorrectly emit R_REL_COPY relocations, breaking tables-next-to-code. We've known about it for several years now and there is not yet a fix upstream. Previously we would simply force use of ld.gold on ARM. However, given the rework of linking configuration, I thought a more principled solution was in order. Test Plan: Validate on armv7 Reviewers: austin, hvr Subscribers: angerman, rwbarton, thomie, erikd GHC Trac Issues: #4210 Differential Revision: https://phabricator.haskell.org/D3676
* Revert "Remove the Windows GCC driver."Simon Peyton Jones2017-06-291-2/+1
| | | | | | | | | | | | | | | | | | This reverts commit d6cecde585b0980ed8e0050c5a1d315789fb6356. The patch broke Simon PJ's Windows build, becuase he didn't have (and should not need) a separate msys2 gcc. Following an exchange on the ghc-devs list, Tamar wrote Oops, sorry, didn’t notice it because both mine and harbormaster’s msys2 have separate GCCs installed as well. I don’t see an easy fix that would also work for end user Configure based cabal installs. So I think I’ll have to go back to the drawing board for this one. You can just leave it reverted.
* Remove the Windows GCC driver.Tamar Christina2017-06-171-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch drops the GCC driver and instead moves the only remaining path that we need to keep for backwards compatibility to the settings file. It also generalizes the code that expands `$TopDir` so it can expand it within any location in the string and also changes it so `$TopDir` is expanded only after the words call because `$TopDir` can contains spaces which would be horribly broken. Test Plan: ./validate Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, erikd GHC Trac Issues: #13709 Differential Revision: https://phabricator.haskell.org/D3592
* Provide way to build using existing C compiler on Windows.Tamar Christina2017-06-171-5/+17
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: There are various distros that build GHC using their own C compilers such as MSYS2. Currently they have to patch the build scripts everytime. This patch provides the configure argument `--enable-distro-toolchain` which allows one to build using any C compiler on the path. This is also useful for testing new versions of GCC. Test Plan: ./configure --enable-distro-toolchain && make - && make THREADS=9 test ./validate Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, erikd, #ghc_windows_task_force GHC Trac Issues: #13792 Differential Revision: https://phabricator.haskell.org/D3637
* Check target libtoolMoritz Angermann2017-06-081-2/+7
| | | | | | | | | | | | | 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
* aclocal: Fix regression in linker detectionBen Gamari2017-06-021-1/+1
| | | | | | 5ddb307edf15c4d86e5c35c4063ec967424e19f2 regressed autoconf's ability to find the linker due to a silly variable interpolation issue, causing segmentation faults on AArch64.
* aclocal.m4: add support for versioned darwin tripletsSergei Trofimovich2017-06-011-0/+3
| | | | | | | | The change adds support for 'darwin*' OS: $ ./configure --target=aarch64-apple-darwin14 Reported-by: jp_rider Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
* aclocal.m4: allow override of dllwrap and windres when cross-compilingSergei Trofimovich2017-05-231-2/+12
| | | | | | | | | | | | | | | | | Commit 66108864540601837ad77847f4062a670362361f reverted ability to override 'dllwrap' and 'windres' paths when cross-compiling. After this change (and a few libraries/Win32 patches) I was able to build cross-compiler to windows: $ ./configure --target=i686-w64-mingw32 \ DllWrap=i686-w64-mingw32-dllwrap \ Windres=i686-w64-mingw32-windres Later both 'dllwrap' and 'windres' should be derived from --target= as we do now for 'CC', 'AR', 'NM' and others. Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
* Typos [ci skip]Gabor Greif2017-05-121-1/+1
|
* Pass LLVMTarget (identical to --target)Moritz Angermann2017-05-111-0/+5
| | | | | | | | | | | | | | | | 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
* Drop custom apple handlingMoritz Angermann2017-05-111-31/+19
| | | | | | | | | | | | | | | 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
* Do not hardcode the specific linker to useMoritz Angermann2017-05-111-11/+26
| | | | | | | | | | | | | | | | | 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
* Fix Raspberry PiMoritz Angermann2017-05-081-12/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* configure: Kill off FP_ARG_WITH_*Ben Gamari2017-04-251-87/+14
| | | | | | | | | | | | | | | | | 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
* Revert "Remove special casing of Windows in generic files"Ben Gamari2017-04-251-31/+18
| | | | | | | | This commit didn't consider the fact that binary distributions on Windows must have relative toolchain paths. This caused #13560. This reverts commit 48385cb2fc295eb8af9188cbe140142c1807d5a7 (except for a helpful comment).
* aclocal.m4: treat '*-w64-mingw32' targets as windowsSergei Trofimovich2017-04-231-1/+2
| | | | | | | | Noticed when tried to cross-compile GHC from x86_64-linux to --target=i686-w64-mingw32. Final ghc executables did not have '.exe' extensions. Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
* aclocal.m4: respect user's --with-ar= choiceSergei Trofimovich2017-04-171-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | '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]) ArCmd="$AR" fp_prog_ar="$AR" AC_SUBST([ArCmd]) The change keeps that value. Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
* Various patches to support android cross compilationMoritz Angermann2017-03-291-1/+1
| | | | | | | | | | | | | | | | | | | | - Better test for SHT_INIT_ARRAY than openbsd_HOST_OS This is actually bens patch: https://gist.github.com/bgamari/c846e6a5f2cd988716cd5e36c68d5bef - linux-android defines. - No need for -lpthread on OSAndroid However, I’m confused why we do not use the AC NEED_PTHREAD_LIB value here? - Use mmap on android - Support `none` vendor. Reviewers: austin, hvr, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D3356
* Check TargetPlatform instead of HostPlatform for leading underscoreMoritz Angermann2017-03-291-1/+3
| | | | | | | | | | Reviewers: austin, hvr, rwbarton, bgamari Reviewed By: rwbarton, bgamari Subscribers: rwbarton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D3348
* Typos and grammar in manual/commentsGabor Greif2017-01-231-1/+1
|
* Clean up some shell code and M4 quotingDemi Obenour2017-01-201-7/+6
| | | | | | | | | | | | Test Plan: GHC CI Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie, erikd Differential Revision: https://phabricator.haskell.org/D2993
* fix OpenBSD linkage (wxneeded)Sergei Trofimovich2016-12-171-1/+1
| | | | | | | | | | | | | | | | | | | | There is two types of options passed directly to 'ld' (and not to 'gcc' driver): - CONF_LD_LINKER_OPTS_STAGE$4 - EXTRA_LD_OPTS This changedoes two things: - split 'EXTRA_LD_OPTS' into two variables: - EXTRA_LD_OPTS (accepts 'gcc' wrapper options) - EXTRA_LD_LINKER_OPTS (accepts raw 'ld' options) - wraps all LD_LINKER options as '-Wl,' when passed to 'gcc' driver. Fixes https://phabricator.haskell.org/D2776 Signed-off-by: Sergei Trofimovich <siarheit@google.com>
* configure: Verify that GCC recognizes -no-pie flagBen Gamari2016-11-141-1/+2
| | | | | | | | | | | | | | | | | It seems like GCC versions prior to 4.8 exit with code 0 when faced with an unrecognized flag. Silly compilers. Test Plan: Validate Reviewers: hvr, austin, ggreif Reviewed By: ggreif Subscribers: thomie, erikd Differential Revision: https://phabricator.haskell.org/D2707 GHC Trac Issues: #12759
* Pass -no-pie to GCCBen Gamari2016-11-111-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | 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-18/+0
| | | | | | This reverts commit bae4a55b1fb403f610b4b55a1b6fb3f03e9c2026. This will be superceded by D2693.
* Pass -no-pie to GCCBen Gamari2016-11-101-0/+18
| | | | | | | | | | | | | | | | | | 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
* pass -z wxneeded or -Wl,-zwxneeded for linking on OpenBSDKarel Gardas2016-08-221-0/+7
| | | | | | | | | | | | | | | | | Summary: 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
* Adds x86_64-apple-darwin14 target.Moritz Angermann2016-07-051-2/+2
| | | | | | | | | | | | | | | | | | 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
* Remove special casing of Windows in generic filesTamar Christina2016-06-091-18/+31
| | | | | | | | | | | | | | | | | | 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
* Suppress the warning about __sync_fetch_and_nand (#9678)Thomas Miedema2016-05-241-0/+3
|
* Use stdint types to define SIZEOF and ALIGNMENT of INTx/WORDxTomas Carnecky2016-04-181-0/+10
| | | | | | | | | | | | | 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-35/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Autoconf: detect and set CFLAGS/CPPFLAGS needed for C99 modeHerbert Valerio Riedel2016-03-281-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Drop Xcode 4.1 hack and fix ignored CC var issueHerbert Valerio Riedel2016-03-281-10/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Scrap DEC OSF/1 supportHerbert Valerio Riedel2016-03-281-6/+2
| | | | | | | | | | | | | 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 code-base. 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
* Scrap IRIX supportHerbert Valerio Riedel2016-03-281-2/+2
| | | | | | | | | | | | | | | | 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 support. R.I.P. IRIX [1]: https://en.wikipedia.org/wiki/IRIX
* Add NCG support for AIX/ppc32Herbert Valerio Riedel2016-03-241-9/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 function-descriptor. Reviewers: austin, trommler, erikd, bgamari Reviewed By: trommler, erikd, bgamari Differential Revision: https://phabricator.haskell.org/D2019
* Ensure that we don't produce code for pre-ARMv7 without barriersBen Gamari2016-01-251-0/+2
| | | | | | | | | | | | | | | | | | | | | | 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
* Build system: fix `pwd` issues on WindowsThomas Miedema2016-01-081-1/+9
| | | | | | | | | | | | | 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