summaryrefslogtreecommitdiff
path: root/driver/utils
Commit message (Collapse)AuthorAgeFilesLines
* Rename _closure to _static_closure, apply naming consistently.Edward Z. Yang2014-10-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In preparation for indirecting all references to closures, we rename _closure to _static_closure to ensure any old code will get an undefined symbol error. In order to reference a closure foobar_closure (which is now undefined), you should instead use STATIC_CLOSURE(foobar). For convenience, a number of these old identifiers are macro'd. Across C-- and C (Windows and otherwise), there were differing conventions on whether or not foobar_closure or &foobar_closure was the address of the closure. Now, all foobar_closure references are addresses, and no & is necessary. CHARLIKE/INTLIKE were not changed, simply alpha-renamed. Part of remove HEAP_ALLOCED patch set (#8199) Depends on D265 Signed-off-by: Edward Z. Yang <ezyang@mit.edu> Test Plan: validate Reviewers: simonmar, austin Subscribers: simonmar, ezyang, carter, thomie Differential Revision: https://phabricator.haskell.org/D267 GHC Trac Issues: #8199
* Make dynamic GHC no Windows installable tooIan Lynagh2013-05-161-3/+1
| | | | | We need different paths in the wrapper, as teh installed tree is a different shape to the build tree.
* Define the right RTS config in the Windows dyn wrapper programsIan Lynagh2013-05-141-3/+5
| | | | | | This is particularly important as without it validate fails, as it tries to pass RTS options to haddock, and with the default RTS config those options aren't permitted.
* More work towards dynamic programs on WindowsIan Lynagh2013-05-121-0/+197
| | | | | | | | | | | | | | | | | | | Dynamic GHC is now working in-place, but pathologically slow due to the DLL split. (GHC assumes that all intra-package calls are in the same DLL, but that isn't true when we split the GHC package into 2 DLLs. That means that GHC's startup time is around 22 seconds, as it is doing run-time linking). Also, ghci isn't actually working yet: $ inplace/bin/ghc-stage2 --interactive GHCi, version 7.7.20130512: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... <command line>: can't load .so/.DLL for: HSghc-prim-0.3.1.0.dll (addDLL: could not load DLL) ghc-stage2.exe: HSghc-prim-0.3.1.0: The specified module could not be found.
* Fix a tiny bug in cwrapper.cIan Lynagh2012-03-161-3/+3
| | | | Caught by -Werror
* use Win32 CreateProcess() rather than mingw spawnv() (#4531)Simon Marlow2011-01-061-37/+94
|
* Fix build on WindowsIan Lynagh2010-02-192-3/+2
|
* Refactor gcc.c, pulling out the reusable codeIan Lynagh2010-02-182-0/+105
|
* Wrap gcc on Windows, to provide the -B flagsIan Lynagh2009-10-272-0/+44