summaryrefslogtreecommitdiff
path: root/aclocal.m4
Commit message (Collapse)AuthorAgeFilesLines
* aclocal.m4: add minimal support for nios2 architectureSergei Trofimovich2017-12-251-1/+4
| | | | | | | | | With this change unregisterised port can already produce minimal executables: ELF 32-bit LSB executable, Altera Nios II, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-nios2.so.1 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
* configure: Fix ar probed flagsBen Gamari2017-11-211-4/+8
| | | | | | | | | | | | | | | | | | | | | | FP_PROG_AR_ARGS appears to be probing for what flags to use to build an archive with an index. However, none of the flags that it probed previously were valid as they all started with `c`, which isn't a mode character. This went unnoticed until someone attempted to use LLVM ar since we have a special case for gnu ar. Additionally, we work around a bug in llvm-ar 5.0 where ar will exit with code 0 even if it fails to parse the command line. Silliness. I believe these should rather all be mode `q` however I'll need to test this on a few platforms to be certain. Test Plan: Validate on OS X, BSD, and Linux with binutils and llvm ar Reviewers: hvr Subscribers: rwbarton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D4214
* Adds rts/rts.cabal.in fileMoritz Angermann2017-11-151-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | This is in preparation for cabalification of the `rts`. To be actually able to parse this file, a rather recent Cabal is required. One after commit 357d49d of haskell/cabal. The relevant PR to support the new `asm-sources` and `cmm-sources` is haskell/cabal/pull/4857. Not that this does *not* allow cabal to build the RTS. It does however provide enough information such that cabal can `copy` and `register` the package properly in the package database, if all the build artifacts have been build properly. As such it does not require any custom handling of the `rts` package. As the rts as well as all the other packages built by the GHC built system are built outside of cabal anyway. Reviewers: bgamari, hvr, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D4174
* Update autoconf test for gcc to require 4.7 and upPeter Trommler2017-11-061-14/+2
| | | | | | | | | | | | | | | | | | | Fixing #14244 required the newer gcc atomic built-ins that are provided from 4.7 and up. This updates the test to check for minimum gcc version 4.7. The version tests for 3.4 (!), 4.4, and 4.6 are no longer needed and can be removed. This makes the build system simpler. Test Plan: validate Reviewers: austin, bgamari, hvr, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D4165
* configure: Add Alpine Linux to checkVendorTuncer Ayaz2017-10-261-1/+1
|
* configure: Fix CC version check on Apple compilersBen Gamari2017-10-161-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | It seems that some Apple LLVM wrappers emit multiple messages containing the string "version", which we previously used to find the version number. For instance, Configured with: --prefix=/Applications/Xcode.app/Contents/... Apple LLVM version 9.0.0 (clang-900.0.37) Target: x86_64-apple-darwin16.7.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/... Found CUDA installation: /usr/local/cuda, version 8.0 We now take care to only look at the first occurrence of this string. New `sed` command due to @merijn. Test Plan: Validate on all the compilers Reviewers: austin, hvr Subscribers: rwbarton, thomie, merijn, erikd Differential Revision: https://phabricator.haskell.org/D4069
* configure: Accept *-msys as a Windows OS in a tripleBen Gamari2017-10-041-1/+1
|
* Fix Raspberry Pi target nameMoritz Angermann2017-09-291-1/+1
| | | | | | | | | | | | | | Summary: For some reson, the `*`, that was supposed to be in D4031 got lost in the diff. Reviewers: bgamari, austin, hvr, dfeuer Reviewed By: dfeuer Subscribers: rwbarton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D4044
* configure: Make sure we try all possible linkersBen Gamari2017-09-271-18/+41
| | | | | | | | | | | | | | | | | | | | Previously if we had both ld.lld and ld.gold installed but a gcc which didn't support -fuse-ld=lld we would fail when trying ld.lld and fall immediately back to plain ld. Now we will try ld.gold as well. This was brought to light by #14280, where using ld.bfd resulted in a broken stage2 compiler. Test Plan: Configure Reviewers: angerman, hvr, austin Reviewed By: angerman Subscribers: rwbarton, thomie, erikd GHC Trac Issues: #14280 Differential Revision: https://phabricator.haskell.org/D4038
* GHC_LLVM_TARGET: Keep android OSMoritz Angermann2017-09-271-0/+8
| | | | | | | | | | | | | | | Summary: Our usual GHC_CONVERT_OS macro, will turn any andoird* into android. This however drops the essential androideabi part. As such for the GHC_LLVM_TARGET we only convert the VENDOR, not the OS. Reviewers: bgamari, austin, hvr Reviewed By: bgamari Subscribers: rwbarton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D4031
* configure: Catch case where LLVM tools can't be foundBen Gamari2017-09-251-1/+3
| | | | | | | | | | | | | | Previously we didn't specify the prog-not-found value passed to AC_CHECK_TOOLS. Reported by @snowleopard in https://github.com/snowleopard/hadrian/issues/415. Test Plan: validate Reviewers: austin, hvr Subscribers: rwbarton, thomie, snowleopard, erikd Differential Revision: https://phabricator.haskell.org/D3992
* Adds mingw64 to the valid GHC OSs.Moritz Angermann2017-09-261-0/+4
| | | | | | | | | | | | | | | Summary: This fixes hadrian#420 (https://github.com/snowleopard/hadrian/issues/420) specifically the "Unknown OS mingw64". Reviewers: austin, hvr, bgamari, Phyx Reviewed By: Phyx Subscribers: rwbarton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D4016
* Fix the searching of target AR toolTamar Christina2017-09-261-4/+12
| | | | | | | | | | | | | | | | | | | | Summary: Ar was being checked twice prior to D3883 where I removed one of the checks because the converted path was being overridden after the check because of the second check for Ar. However the one in configure.ac was a target check so I'm changing the path check to a target check now. Test Plan: ./configure Reviewers: angerman, austin, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, erikd GHC Trac Issues: #14274 Differential Revision: https://phabricator.haskell.org/D4020
* Additional LLVM_TARGET logic.Moritz Angermann2017-09-231-2/+22
| | | | | | | | | | | | | | | | | | Summary: This should help resolve the compilcation that came up in Trac #14261 Test Plan: validate on various platforms Reviewers: trofi, bgamari, austin, hvr Reviewed By: trofi Subscribers: rwbarton, thomie, erikd GHC Trac Issues: #14261 Differential Revision: https://phabricator.haskell.org/D4004
* aclocal.m4: call cygpath on mingw32 onlySergei Trofimovich2017-09-201-2/+2
| | | | | | | | | | | | | | | | The only reason I noticed is warning these lines on linux: ``` $ ./configure --target=sparc-unknown-linux-gnu ... ./configure: line 9708: cygpath: command not found ./configure: line 9708: ArCmd: command not found ``` POSIX shell syntax requires no spaces in assignments. Fixed guarding condition while at it. Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
* Use ar for -staticlibMoritz Angermann2017-09-131-0/+3
| | | | | | | | | | | | | | | | Hopefully we can get rid of libtool, by using ar only Depends on: D3579 Test Plan: validate Reviewers: austin, hvr, bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D3721
* 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
View Lorry Controller Status