summaryrefslogtreecommitdiff
path: root/m4
Commit message (Collapse)AuthorAgeFilesLines
* Fix GHCJS OS platform (fix #23346)Sylvain Henry2023-05-151-1/+1
|
* configure: Fix FIND_CXX_STD_LIB test on DarwinBen Gamari2023-03-161-0/+11
| | | | | | | | Annoyingly, Darwin's <cstddef> includes <version> and APFS is case-insensitive. Consequently, it will end up #including the `VERSION` file generated by the `configure` script on the second and subsequent runs of the `configure` script. See #23116.
* Small fixes to configure scriptGabriella Gonzalez2023-03-061-2/+2
|
* Fix configure failure on alpine linuxGabriella Gonzalez2023-03-061-1/+2
|
* Quote variablesGabriella Gonzalez2023-03-061-4/+3
| | | | … as suggested by @bgamari
* Try to create somewhat portable `ld` commandGabriella Gonzalez2023-03-061-1/+1
| | | | | | | I cannot figure out a good way to generate an `ld` command that works on both Linux and macOS. Normally you'd use something like `AC_LINK_IFELSE` for this purpose (I think), but that won't let us test response file support.
* Apply 1 suggestion(s) to 1 file(s)sheaf2023-03-061-1/+1
|
* Enable response files for linker if supportedGabriella Gonzalez2023-03-061-0/+19
|
* JS: replace "js" architecture with "javascript"Sylvain Henry2023-02-063-4/+4
| | | | | | | | | | | | | | | Despite Cabal supporting any architecture name, `cabal --check` only supports a few built-in ones. Sadly `cabal --check` is used by Hackage hence using any non built-in name in a package (e.g. `arch(js)`) is rejected and the package is prevented from being uploaded on Hackage. Luckily built-in support for the `javascript` architecture was added for GHCJS a while ago. In order to allow newer `base` to be uploaded on Hackage we make the switch from `js` to `javascript` architecture. Fixes #22740. Co-authored-by: Ben Gamari <ben@smart-cactus.org>
* Enable tables next to code for LoongArch64lrzlin2023-02-031-1/+1
|
* configure: support "windows" as an OSSylvain Henry2023-01-252-2/+5
|
* Give the RTS it's own configure scriptJohn Ericson2023-01-181-3/+0
| | | | | | | | | | | | | Currently it doesn't do much anything, we are just trying to introduce it without breaking the build. Later, we will move functionality from the top-level configure script over to it. We need to bump Cabal for https://github.com/haskell/cabal/pull/8649; to facilitate and existing hack of skipping some configure checks for the RTS we now need to skip just *part* not *all* of the "post configure" hook, as running the configure script (which we definitely want to do) is also implemented as part of the "post configure" hook. But doing this requires exposing functionality that wasn't exposed before.
* Change MSYSTEM to CLANG64 uniformlyCheng Shao2023-01-121-1/+1
|
* configure: Fix escaping of `$tooldir`Ben Gamari2023-01-121-4/+4
| | | | | | | | | In !9547 I introduced `$tooldir` directories into GHC's default link and compilation flags to ensure that our C toolchain finds its own headers and libraries before others on the system. However, the patch was subtly wrong in the escaping of `$tooldir`. Fix this. Fixes #22561.
* m4/fp_leading_underscore.m4: Avoid implicit exit function declarationFlorian Weimer2023-01-111-6/+4
| | | | | | | And switch to a new-style function definition. Fixes build issues with compilers that do not accept implicit function declarations.
* Store bootstrap_llvm_target and use it to set LlvmTarget in bindistsMatthew Pickering2023-01-091-1/+6
| | | | | | | | | | This mirrors some existing logic for the bootstrap_target which influences how TargetPlatform is set. As described on #21970 not storing this led to `LlvmTarget` being set incorrectly and hence the wrong `--target` flag being passed to the C compiler. Towards #21970
* Pass -Wl,-no_fixup_chains to ld64 when appropiateMatthew Pickering2023-01-071-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recent versions of MacOS use a version of ld where `-fixup_chains` is on by default. This is incompatible with our usage of `-undefined dynamic_lookup`. Therefore we explicitly disable `fixup-chains` by passing `-no_fixup_chains` to the linker on darwin. This results in a warning of the form: ld: warning: -undefined dynamic_lookup may not work with chained fixups The manual explains the incompatible nature of these two flags: -undefined treatment Specifies how undefined symbols are to be treated. Options are: error, warning, suppress, or dynamic_lookup. The default is error. Note: dynamic_lookup that depends on lazy binding will not work with chained fixups. A relevant ticket is #22429 Here are also a few other links which are relevant to the issue: Official comment: https://developer.apple.com/forums/thread/719961 More relevant links: https://openradar.appspot.com/radar?id=5536824084660224 https://github.com/python/cpython/issues/97524 Note in release notes: https://developer.apple.com/documentation/xcode-release-notes/xcode-13-releas e-notes
* Revert "configure: Drop uses of AC_PROG_CC_C99"Matthew Pickering2023-01-051-0/+38
| | | | | | | | | | This reverts commit 7c6de18dd3151ead954c210336728e8686c91de6. Centos7 using a very old version of the toolchain (autotools-2.69) where the behaviour of these macros has not yet changed. I am reverting this without haste as it is blocking the 9.6 branch. Fixes #22704
* compiler: Ensure that GHC toolchain is first in search pathBen Gamari2022-12-241-4/+4
| | | | | | | As noted in #22561, it is important that GHC's toolchain look first for its own headers and libraries to ensure that the system's are not found instead. If this happens things can break in surprising ways (e.g. see #22561).
* configure: Drop uses of AC_PROG_CC_C99Ben Gamari2022-12-201-38/+0
| | | | | | | As noted in #22566, this macro is deprecated as of autoconf-2.70 `AC_PROG_CC` now sets `ac_cv_prog_cc_c99` itself. Closes #22566.
* Add initial support for LoongArch Architecture.lrzlin2022-12-084-3/+12
|
* Add Javascript backendSylvain Henry2022-11-294-1/+13
| | | | | | | | | | | | | | | Add JS backend adapted from the GHCJS project by Luite Stegeman. Some features haven't been ported or implemented yet. Tests for these features have been disabled with an associated gitlab ticket. Bump array submodule Work funded by IOG. Co-authored-by: Jeffrey Young <jeffrey.young@iohk.io> Co-authored-by: Luite Stegeman <stegeman@gmail.com> Co-authored-by: Josh Meredith <joshmeredith2008@gmail.com>
* Redirect output of musttail attribute testWill Hawkins2022-11-261-1/+1
| | | | | Compilation output from test for support of musttail attribute leaked to the console.
* Don't let configure perform trivial substitutions (#21846)Sylvain Henry2022-11-233-7/+8
| | | | | | | | | | | | | | Hadrian now performs substitutions, especially to generate .cabal files from .cabal.in files. Two benefits: 1. We won't have to re-configure when we modify thing.cabal.in. Hadrian will take care of this for us. 2. It paves the way to allow the same package to be configured differently by Hadrian in the same session. This will be useful to fix #19174: we want to build a stage2 cross-compiler for the host platform and a stage1 compiler for the cross target platform in the same Hadrian session.
* configure: Don't check for an unsupported version of LLVMARATA Mizuki2022-11-151-1/+1
| | | | | | The upper bound is not inclusive. Fixes #22449
* Clarify that LLVM upper bound is non-inclusive during configure (#22411)Zubin Duggal2022-11-111-3/+3
|
* Add support for the wasm32-wasi target tupleCheng Shao2022-11-115-2/+14
| | | | | | This patch adds the wasm32-wasi tuple support to various places in the tree: autoconf, hadrian, ghc-boot and also the compiler. The codegen logic will come in subsequent commits.
* build: get rid of `HAVE_TIME_H`Nicolas Trangez2022-10-211-2/+0
| | | | | | | | | | | | As advertized by `autoreconf`: > All current systems provide time.h; it need not be checked for. Hence, remove the check for it in `configure.ac` and remove conditional inclusion of the header in `HAVE_TIME_H` blocks where applicable. The `time.h` header was being included in various source files without a `HAVE_TIME_H` guard already anyway.
* CmmToC: emit explicit tail calls when the C compiler supports itCheng Shao2022-10-111-0/+16
| | | | | | | | | | | | | | | Clang 13+ supports annotating a return statement using the musttail attribute, which guarantees that it lowers to a tail call if compilation succeeds. This patch takes advantage of that feature for the unregisterised code generator. The configure script tests availability of the musttail attribute, if it's available, the Cmm tail calls will become C tail calls that avoids the mini interpreter trampoline overhead. Nothing is affected if the musttail attribute is not supported. Clang documentation: https://clang.llvm.org/docs/AttributeReference.html#musttail
* Repair c++ probing on OpenBSDGreg Steuck2022-09-141-0/+1
| | | | | | | | | | Failure without this change: ``` checking C++ standard library flavour... libc++ checking for linkage against 'c++ c++abi'... failed checking for linkage against 'c++ cxxrt'... failed configure: error: Failed to find C++ standard library ```
* Windows: Always define _UCRT when compiling C codeRyan Scott2022-09-121-1/+5
| | | | | | | As seen in #22159, this is required to ensure correct behavior when MinGW-w64 headers are in the `C_INCLUDE_PATH`. Fixes #22159.
* compiler: Drop --build-id=none hackBen Gamari2022-08-181-20/+0
| | | | | | | | | Since 2011 the object-joining implementation has had a hack to pass `--build-id=none` to `ld` when supported, seemingly to work around a linker bug. This hack is now unnecessary and may break downstream users who expect objects to have valid build-ids. Remove it. Closes #22060.
* system-cxx-std-lib: Add support for FreeBSD libcxxrtBen Gamari2022-08-091-20/+55
|
* Statically-link against libc++ on WindowsBen Gamari2022-07-161-0/+7
| | | | | | | | | | | Unfortunately on Windows we have no RPATH-like facility, making dynamic linking extremely fragile. Since we cannot assume that the user will add their GHC installation to `$PATH` (and therefore their DLL search path) we cannot assume that the loader will be able to locate our `libc++.dll`. To avoid this, we instead statically link against `libc++.a` on Windows. Fixes #21435.
* configure: Don't override Windows CXXFLAGSBen Gamari2022-07-161-1/+1
| | | | | | | | | | | | | | At some point we used the clang distribution from msys2's `MINGW64` environment for our Windows toolchain. This defaulted to using libgcc and libstdc++ for its runtime library. However, we found for a variety of reasons that compiler-rt, libunwind, and libc++ were more reliable, consequently we explicitly overrode the CXXFLAGS to use these. However, since then we have switched to use the `CLANG64` packaging, which default to these already. Consequently we can drop these arguments, silencing some redundant argument warnings from clang. Fixes #21669.
* Suppress extra output from configure check for c++ librariesGreg Steuck2022-07-161-2/+2
|
* configure: Don't attempt to override linker on DarwinBen Gamari2022-06-151-1/+8
| | | | | | | | | | | | | | | | Configure's --enable-ld-override functionality is intended to ensure that we don't rely on ld.bfd, which tends to be slow and buggy, on Linux and Windows. However, on Darwin the lack of sensible package management makes it extremely easy for users to have awkward mixtures of toolchain components from, e.g., XCode, the Apple Command-Line Tools package, and homebrew. This leads to extremely confusing problems like #21712. Here we avoid this by simply giving up on linker selection on Darwin altogether. This isn't so bad since the Apple ld64 linker has decent performance and AFAICT fairly reliable. Closes #21712.
* configure: Hide spurious warning from ldBen Gamari2022-06-151-1/+1
| | | | | | Previously the check_for_gold_t22266 configure check could result in spurious warnings coming from the linker being blurted to stderr. Suppress these by piping stderr to /dev/null.
* Remove -z wxneeded for OpenBSDGreg Steuck2022-05-241-7/+0
| | | | | | | With all the recent W^X fixes in the loader this workaround is not necessary any longer. I verified that the only tests failing for me on OpenBSD 7.1-current are the same (libc++ related) before and after this commit (with --fast).
* configure: Check CC_STAGE0 for --target supportBen Gamari2022-05-191-9/+10
| | | | | | | | | | | | | | We previously only checked the stage 1/2 compiler for --target support. We got away with this for quite a while but it eventually caught up with us in #21579, where `bytestring`'s new NEON implementation was unbuildable on Darwin due to Rosetta's seemingly random logic for determining which executable image to execute. This lead to a confusing failure to build `bytestring`'s cbits, when `clang` tried to compile NEON builtins while targetting x86-64. Fix this by checking CC_STAGE0 for --target support. Fixes #21579.
* Introduce package to capture dependency on C++ stdlibBen Gamari2022-05-171-0/+58
| | | | | | | | Here we introduce a new "virtual" package into the initial package database, `system-cxx-std-lib`. This gives users a convenient, platform agnostic way to link against C++ libraries, addressing #20010. Fixes #20010.
* driver: Introduce pgmcxxBen Gamari2022-05-172-0/+4
| | | | | | | | | | Here we introduce proper support for compilation of C++ objects. This includes: * logic in `configure` to detect the C++ toolchain and propagating this information into the `settings` file * logic in the driver to use the C++ toolchain when compiling C++ sources
* FIND_LLVM_PROG: Recognize llvm suffix used by FreeBSD, ie llc10.mikael2022-05-111-2/+2
|
* configure: Check for ffi.hBen Gamari2022-05-101-3/+10
| | | | | | | As noted in #21485, we checked for ffi.h yet then failed to throw an error if it is missing. Fixes #21485.
* Drop remaining vestiges of libtoolBen Gamari2022-04-251-6/+0
| | | | | | | | | | | | | Drop libtool logic from gen-dll, allowing us to drop the remaining logic from the `configure` script. Strangely, this appears to reliably reduce compiler allocations of T16875 on Windows. Closes #18826. Metric Decrease: T16875
* configure: Make environ decl check more robustBen Gamari2022-04-071-2/+5
| | | | | Some platforms (e.g. Windows/clang64) declare `environ` in `<stdlib.h>`, not `<unistd.h>`
* Windows/Clang: Build system adaptationBen Gamari2022-04-062-68/+184
| | | | | | | | | | * Bump win32-tarballs to 0.7 * Move Windows toolchain autoconf logic into separate file * Use clang and LLVM utilities as described in #21019 * Disable object merging as lld doesn't support -r * Drop --oformat=pe-bigobj-x86-64 arguments from ld flags as LLD detects that the output is large on its own. * Drop gcc wrapper since Clang finds its root fine on its own.
* hadrian: Produce ar archives with L modifier on WindowsBen Gamari2022-04-061-0/+30
| | | | | | | | Since object files may in fact be archive files, we must ensure that their contents are merged rather than constructing an archive-of-an-archive. See #21068.
* fp_prog_ar.m4: take AR var into considerationAdrian Ratiu2022-04-011-1/+2
| | | | | | | | | | In ChromeOS and Gentoo we want the ability to use LLVM ar instead of GNU ar even though both are installed, thus we pass (for eg) AR=llvm-ar to configure. Unfortunately GNU ar always gets picked regardless of the AR setting because the check does not consider the AR var when setting fp_prog_ar, hence this fix.
* Always define __GLASGOW_HASKELL_PATCHLEVEL1/2__ macrosMatthew Pickering2022-02-171-0/+4
| | | | | | | | | | | | As #21076 reports if you are using `-Wcpp-undef` then you get warnings when using the `MIN_VERSION_GLASGOW_HASKELL` macro because __GLASGOW_HASKELL_PATCHLEVEL2__ is very rarely explicitliy set (as version numbers are not 4 components long). This macro was introduced in 3549c952b535803270872adaf87262f2df0295a4 and it seems the bug has existed ever since. Fixes #21076
View Lorry Controller Status