summaryrefslogtreecommitdiff
path: root/driver/utils/dynwrapper.c
Commit message (Collapse)AuthorAgeFilesLines
* Lowercase windows importsMoritz Angermann2019-05-271-2/+2
| | | | | | | | | | While windows and macOS are currently on case-insensitive file systems, this poses no issue on those. When cross compiling from linux with a case sensitive file system and mingw providing only lowercase headers, this in fact produces an issue. As such we just lowercase the import headers, which should still work fine on a case insensitive file system and also enable mingw's headers to be usable porperly.
* driver/utils/dynwrapper.c: Remove unused variableSimon Jakobi2018-02-251-1/+0
| | | | | | | | | | | | | | | The variable was already unused when the file was introduced in b35a6ce0e34255d200ddcf341ffc645fd237ea32. Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #11777 Differential Revision: https://phabricator.haskell.org/D4426
* Revert "Rename _closure to _static_closure, apply naming consistently."Edward Z. Yang2014-10-201-1/+1
| | | | | | | This reverts commit 35672072b4091d6f0031417bc160c568f22d0469. Conflicts: compiler/main/DriverPipeline.hs
* 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.
View Lorry Controller Status