summaryrefslogtreecommitdiff
path: root/libffi/ghc.mk
Commit message (Collapse)AuthorAgeFilesLines
* Update Wiki URLs to point to GitLabTakenobu Tani2019-03-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | This moves all URL references to Trac Wiki to their corresponding GitLab counterparts. This substitution is classified as follows: 1. Automated substitution using sed with Ben's mapping rule [1] Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy... New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy... 2. Manual substitution for URLs containing `#` index Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...#Zzz New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...#zzz 3. Manual substitution for strings starting with `Commentary` Old: Commentary/XxxYyy... New: commentary/xxx-yyy... See also !539 [1]: https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mapping.json
* No libffi docsMoritz Angermann2017-10-031-0/+1
| | | | | | | | | | | | | | Summary: building libffi docs with our intree-libffi seems rather pointless. Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4054
* Allow libffi snapshotsMoritz Angermann2017-09-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | This is rather annoying. I'd prefer to have a stable release to use. However libffi-3.2.1 has been released November 12, 2014, and libffi-4 is TBD. See also https://github.com/libffi/libffi/issues/296 The core reason for this change is that llvm changed the supported assembly to unified syntax, which libffi-3.2.1 does not use, and hence fails to compile for arm with llvm. For refence, see the following issue: https://github.com/libffi/libffi/issues/191. This diff contains a script to generate a tarball for the `libffi-tarballs` repository from the libffi GitHub repository; as well as the necessary changes to the build system. Updates libffi-tarballs submodule. Reviewers: austin, bgamari, hvr Subscribers: hvr, erikd, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3574
* Revert "libffi via submodule"Moritz Angermann2017-05-111-4/+5
| | | | This reverts commit 8d4bce42de7929b0dec7e7d68e66bcfc4d266322.
* libffi via submoduleMoritz Angermann2017-05-111-5/+4
| | | | | | | | | | | | | | | | | | | This is rather annoying. I'd prefer to have a stable release to use. However libffi-3.2.1 has been released November 12, 2014, and libffi-4 is TBD. See also https://github.com/libffi/libffi/issues/296 The core reason for this change is that llvm changed the supported assembly to unified syntax, which libffi-3.2.1 does not use, and hence fails to compile for arm with llvm. For refence, see the following issue: https://github.com/libffi/libffi/issues/191 Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, snowleopard Differential Revision: https://phabricator.haskell.org/D3349
* Build system: temp solution for parallelisation bug (#11960)Thomas Miedema2016-05-221-1/+2
|
* Update libffi-tarballs submodule to libffi 3.1 (re #10238)Herbert Valerio Riedel2015-12-081-3/+0
| | | | | | | | | | Reviewers: bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1589 GHC Trac Issues: #10238
* Follow-up fix to 3e2a4eefbed7002437c3f (re #11109)Herbert Valerio Riedel2015-11-221-1/+1
| | | | | | | | | | | Using `:` as sed-`s`-expr separator is not a good idea on windows, as this can result in an expression like 's:@INSTALL@:$(subst ../install-sh,E:/msys64/home/foo/ghc/install-sh,@INSTALL@):g' (note the `E:/` drive component) Using `|` instead of `:` has less risk of collision with the substitution expression
* Fix broken build-system when libffi uses install-shHerbert Valerio Riedel2015-11-191-0/+5
| | | | | | | | | | | | Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1494 GHC Trac Issues: #11109
* Build system: delete half-baked Cygwin supportThomas Miedema2015-08-201-10/+0
| | | | | | | | | | | | | | | | | | | We only support building GHC on mys2 nowadays, see https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows. This (partially) reverts various commits from a few years ago, among which: * 5775d5142da227d65fb86994d363eb16841ee642 "Add OSTYPE build-system variable, and use it" * 3fb8c431824aa2f3bd979e35d1a283546fcfbe74 "Fix building libgmp on cygwin" * cdbb4720c424500adb57cbbef69721d0b039fa46 "Fix cmd invocation by libffi cuild system on Windows 7 cygwin" * e8121501ee3549a35e954726ccfd871ac9d51f83 "Fix dblatex and xml* tool detection on Windows" Reviewed by: austin, Phyx Differential Revision: https://phabricator.haskell.org/D1155
* libffi: backport noexecstack fix for x86/win32.SSergei Trofimovich2015-04-021-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Got detected by gentoo's QA preinstall hook: * RWX --- --- usr/lib/ghc-7.10.1/rts/libffi.so.6.0.2 * RWX --- --- usr/lib/ghc-7.10.1/rts/libffi.so * RWX --- --- usr/lib/ghc-7.10.1/rts/libffi.so.6 * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi.a:win32.o * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_p.a:win32.o * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_l.a:win32.o * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_debug.a:win32.o * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_thr.a:win32.o * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_thr_debug.a:win32.o * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_thr_l.a:win32.o * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_thr_p.a:win32.o Signed-off-by: Sergei Trofimovich <siarheit@google.com> Test Plan: built ghc-7.10.1 binary and checked stacks as NX Reviewers: rwbarton, hvr, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D764 GHC Trac Issues: #10208
* Use the gold linker for linux/ARM and android/ARM targets.Erik de Castro Lopo2015-03-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes #8976 and #9873 by making use of the Binutils ld.gold linker explicit whenever the target is linux/ARM or android/ARM. This does not affect iOS where Apple provides its own linker. In order to achieve this, we need to add `-fuse-ld=gold` to the SettingsCCompilerLinkFlags setting and set SettingsLdCommand to `ld.gold` (or `${target}-ld.gold` when cross-compiling). In addition, simplifying the use of `$(CONF_GCC_LINKER_OPTS_STAGEn)`. This patch was tested by ensuring that the following worked as expected: * Native builds on linux/x86_64 (nothing changed). * Native builds on linux/arm (and uses the gold linker). * Linux to linux/arm cross compiles (and uses the cross gold linker). Contributions by Ben Gamari, Joachim Breitner and Reid Barton. Reviewers: nomeata, bgamari, austin, rwbarton Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D715 GHC Trac Issues: #8976 #9873
* Copy GHC's config.guess/sub over libffi's versionsHerbert Valerio Riedel2014-12-271-0/+4
| | | | | This should address #9924 as GHC's config.guess/sub versions need to be up to date anyway.
* Pass in CXX to libffi's configure script.Gintautas Miliauskas2014-10-241-0/+1
| | | | | | | | | | | | Reviewers: austin Reviewed By: austin Subscribers: thomie, carter, ezyang, simonmar Differential Revision: https://phabricator.haskell.org/D370 GHC Trac Issues: #9720
* Make libffi install into a predictable directory (#9620)Reid Barton2014-09-211-0/+7
| | | | | | | | | On some systems (depending on gcc multilib configuration) libffi would install into libffi/build/inst/lib64 even though we configure it with --libdir=libffi/build/inst/lib. There appears to be no way to get libffi to install to a predictable directory "out of the box", so we apply a small patch to Makefile.in. This is the same fix used in Gentoo's ebuild (https://bugs.gentoo.org/show_bug.cgi?id=462814).
* Globally replace "hackage.haskell.org" with "ghc.haskell.org"Simon Marlow2013-10-011-2/+2
|
* Move libffi's tarball into its own repoIan Lynagh2013-07-301-1/+1
| | | | This means that ghc-tarballs is only needed on Windows
* Change the ranlib detectionIan Lynagh2013-07-031-0/+1
| | | | | | | | On Windows, the ranlib in the path may not be the right ranlib (it may be the 32bit ranlib when we are making a Win64 compiler, or vice-versa). Therefore we can't leave it up to libffi to detect the right ranlib, but need to tell it which ranlib to use. This means that we need to find ranlib even if we don't actually need it ourselves.
* Run "sh ./configure" rather than "sh configure"; part of #7992Ian Lynagh2013-06-221-1/+1
| | | | This fixes a bug with how configure re-execs itself.
* Fix the name of libffiIan Lynagh2013-05-091-2/+6
| | | | | On Windows, we need to keep the DLL called libffi-6.dll (rather than libffi.dll) or Windows can't find it.
* Specify the libdir to use when building libffiIan Lynagh2012-05-261-2/+6
| | | | | Fixes the build on platforms that default to using a directory called lib64. Reported by Gabriel Dos Reis.
* Follow libffi changes on WindowsIan Lynagh2012-05-041-0/+3
|
* Improve support for cross-compilationSimon Marlow2012-01-301-1/+1
| | | | Patchset from Stephen Blackheath <stephen.blackheath@ipwnstudios.com>
* Resurrect UseLibFFIForAdjustors from bitrot.PHO2011-12-081-4/+4
| | | | | | * Pass -Irts/dist/build to the C preprocessor to expose libffi headers (ffi.h and ffitarget.h) to foreign import wrappers during the building process of GHC itself. * Install libffi headers into $(ghcheaderdir) just like any other C headers. Otherwise an installed GHC can't find them when it wants to compile foreign import wrappers. * Include libffi headers in the bindist for the same reason.
* Use touchy rather than touch when building on WindowsIan Lynagh2011-12-021-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With Windows 7 in a vitrual box VM on OS X, some very odd things happen with dates and time stamps when SSHing into cygwin. e.g. here the "Change" time is in the past: $ date; touch foo; stat foo Fri Dec 2 16:58:07 GMTST 2011 File: `foo' Size: 0 Blocks: 0 IO Block: 65536 regular empty file Device: 540aba0bh/1409989131d Inode: 562949953592977 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ ian) Gid: ( 513/ None) Access: 2011-12-02 16:58:07.414457900 +0000 Modify: 2011-12-02 16:58:07.414457900 +0000 Change: 2011-12-02 16:58:03.495141800 +0000 Birth: 2011-12-02 16:57:57.731469900 +0000 And if we copy such a file, then the copy is older (as determined by the "Modify" time) than the original: $ date; touch foo; stat foo; cp foo bar; stat bar Fri Dec 2 16:59:10 GMTST 2011 File: `foo' Size: 0 Blocks: 0 IO Block: 65536 regular empty file Device: 540aba0bh/1409989131d Inode: 1407374883725128 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ ian) Gid: ( 513/ None) Access: 2011-12-02 16:59:10.118457900 +0000 Modify: 2011-12-02 16:59:10.118457900 +0000 Change: 2011-12-02 16:59:06.189477700 +0000 Birth: 2011-12-02 16:57:57.731469900 +0000 File: `bar' Size: 0 Blocks: 0 IO Block: 65536 regular empty file Device: 540aba0bh/1409989131d Inode: 281474976882512 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ ian) Gid: ( 513/ None) Access: 2011-12-02 16:59:06.394555800 +0000 Modify: 2011-12-02 16:59:06.394555800 +0000 Change: 2011-12-02 16:59:06.395532400 +0000 Birth: 2011-12-02 16:58:40.921899600 +0000 This means that make thinks that things are out of date when it shouldn't, so reinvokes itself repeatedly until the MAKE_RESTARTS infinite-recursion test triggers. The touchy program, like most other programs, creates files with both Modify and Change in the past, which is still a little odd, but is consistent, so doesn't break make.
* Fix cmd invocation by libffi cuild system on Windows 7 cygwinIan Lynagh2011-11-301-0/+5
|
* Fix libffi depfile creation on Windows: Use -MD rather than -MMDIan Lynagh2011-11-301-0/+6
|
* Improve the way we call "rm" in the build system; fixes trac #4916Ian Lynagh2011-11-191-8/+8
| | | | | | | | | | We avoid calling "rm -rf" with no file arguments; this fixes cleaning on Solaris, where that fails. We also check for suspicious arguments: anything containing "..", starting "/", or containing a "*" (you need to call $(wildcard ...) yourself now if you really want globbing). This should make things a little safer.
* Fix the libffi ln handling on cygwinIan Lynagh2011-11-081-2/+5
| | | | | iWe were adding c:/... to $PATH, but : is the separator in $PATH.
* On non-Windows, go back to using the libffi dynlib for the dyn wayIan Lynagh2011-10-161-5/+26
|
* Fix ffi build on amd64/Linux, and simplify a little moreIan Lynagh2011-10-141-13/+2
|
* Simplify the libffi buildIan Lynagh2011-10-141-165/+21
| | | | | | | We now put the libffi objects into the RTS library, rather than trying to mangle libffi into being a ghc package itself. It would be nicer to make it a separate library (but not a ghc package), but for now hopefully this will get the build going through on Windows again.
* Build fixes for OS X amd64 following libffi updateIan Lynagh2011-10-061-0/+5
|
* Follow libffi updateIan Lynagh2011-10-061-7/+7
|
* Make and use AR_STAGE[0123] makefile varsIan Lynagh2011-04-231-1/+1
|
* Make stage-specific CC variablesIan Lynagh2011-04-231-2/+2
| | | | | This allows different gcc's to be used when building different stages, which we need to do when cross-compiling.
* Tweak build rules for libffiIan Lynagh2011-04-221-3/+1
| | | | | | | | | We were doing echo $(HOSTPLATFORM) | sed 's/i[567]86/i486/g' but the only x86 value HOSTPLATFORM can have is i386. We now tell libffi its build platform again, but we now tell it it's $(BUILDPLATFORM) rather than $(HOSTPLATFORM).
* no need to set --build when configuring libffiMark Lentczner2011-04-221-2/+1
| | | | | The value --build was set to broke cross-compilier builds, and isn't needed for regular builds.
* libffi: backport incorrect detection of selinuxSergei Trofimovich2011-02-081-0/+2
| | | | | | | | | | | | | | | | | | | | This patch unbreaks ghci on GRSEC kernels hardened with TPE (Trusted Path Execution) protection. TPE forbids mmap('rwx') files opened for writes: fd = open (a_file_in_tmp, O_RDWR); mmap (..., PROT_READ | PROT_WRITE | PROT_EXEC, fd); while allows anonymous RWX mappings: mmap (...MAP_ANONYMOUS , PROT_READ | PROT_WRITE | PROT_EXEC, -1); Thanks to klondike for finding it out. The result of a horrible typo. (unreleased yet) upstream also has the patch: http://github.com/atgreen/libffi/commit/eaf444eabc4c78703c0f98ac0197b1619c1b1bef
* Keep separate linker flags, for when we want to link with gcc or ldIan Lynagh2011-01-241-1/+1
|
* Update the location of libffi.dll.aIan Lynagh2011-01-181-1/+1
| | | | | As far as I can see this has been wrong for some time, but only bit recently.
* Fix libffi build rulesIan Lynagh2011-01-151-1/+3
| | | | | | | | | | Fixes a rare race when both libHSffi.a and libHSffi_p.a were being built at the same time: "cp" libffi/dist-install/build/libffi.a libffi/dist-install/build/libHSffi.a "cp" libffi/dist-install/build/libffi.a libffi/dist-install/build/libHSffi.a "cp" libffi/dist-install/build/libffi.so libffi/dist-install/build/libHSffi-ghc7.1.20110115.so cp: cannot create regular file `libffi/dist-install/build/libHSffi.a': File exists
* Make the ffi.h->ffitarget.h dep a proper dep, rather than an order-only depIan Lynagh2010-10-241-1/+1
|
* libffi: missing dependency on ffitarget.hpho@cielonegro.org2010-10-171-1/+1
| | | | dist-install/build/ffi.h should have a dependency on ffitarget.h as *_stub.c requires it during the stage-2 build.
* Enable shared libs on OpenBSDMatthias Kilian2010-09-181-0/+2
|
* eliminate clutter from make outputSimon Marlow2010-09-151-3/+3
|
* Don't fail with absolute silenceMatthias Kilian2010-09-121-3/+3
|
* Use different CC/LD options for different stagesIan Lynagh2010-07-231-3/+3
|
* quiet some new spewageSimon Marlow2010-07-091-3/+3
|
* Check files are really created in libffiIan Lynagh2010-06-201-0/+6
| | | | | when we think that the libffi build creates them, so they just depend on the libffi build stamp.
View Lorry Controller Status