- User Since
- Nov 5 2014, 3:01 PM (124 w, 3 d)
This unfortunately increases the size of the GHCi libraries.
So much that memory can't be allocated to load them. Have to
figure that out first.
Looking at these again, I suspect a lot of these aren't right. If you look at includes/stg/HaskellMachRegs.h it seems like these MACHREGS_ macros are always defined. just to either 0 or 1.
By switching these from #if to #if defined(..) they're now all trivially always true.
Mon, Mar 20
Sat, Mar 18
Fri, Mar 17
This change potentially breaks tests such as the whitespace and tarball validation tests, as now STAGE1_GHC will always point to the inplace one instead of the ones extracted to the specific folders.
Oops, forgot to press send.
Wed, Mar 15
In the second case, the `.o` is much faster to load than the `.a`, but we aren't building it by default.
Mon, Mar 13
Sun, Mar 12
Sat, Mar 11
Thu, Mar 9
Note to self. Should probably make these scripts smart enough to remove any existing older versions of libraries that it updated. So we prevent it from extracting multiple versions of the same tar to the same place.
Wed, Mar 8
Fair enough, the behavior is a bit counter intuitive to me though. If I understand correctly this is saying that loading the .a is faster than loading the .so?
At least from the Windows point of view this seems odd since DLLs are fully relocated and have no dangling symbols.
Tue, Mar 7
Sort of, I've updated the script so mk/get-win32-tarballs.sh download mirror will get you most things. gcc-libs doesn't seem to have it's source available on the repo and mpc is split into different sources for x86 and x86_64. The script isn't setup to handle that.
Mon, Mar 6
No, I don't believe so. The path containing libwinpthread-1.dll may contain other user installed dlls,
In the case of msys2 this is /mingw64/bin, so removing it would make you not pick up dependencies you should have.
The API used gives precedence to the paths specified over those in the PATH environment. So while it can get overridden
by e.g. spawning a call to ghc from your own program which uses the same APIs, at that point I have to assume that this is the behaviour
No, we always want the one from the inplace gcc distro we provide.
Critically though this patch allows it to work when you don't have one in your environment.
Sun, Mar 5
Tue, Feb 28
This killed the windows build again. Harbormaster said so before the push: https://phabricator.haskell.org/harbormaster/build/21516/
Sun, Feb 26
Feb 23 2017
It would be great if we could also lift the restriction on the boot packages somehow. Maybe by using cabal to first register the new packages in the stage0 compiler in as sandbox or something?
Yeah, having up upgrade the dependencies first is quite a pain..
Feb 22 2017
ugh, that's quite unfortunate...
Feb 21 2017
Feb 20 2017
Ah, that looks better...
- fix linux build
It is possible, arc was being particularly difficult that day. But according to my tree
Feb 19 2017
As can be seen https://phabricator.haskell.org/harbormaster/build/21193/
- fix linux build
https://phabricator.haskell.org/B14010 testsuite build
Feb 18 2017
Feb 16 2017
Passing --trace already makes a test fail, passing any flag to make that's used recursively can make the tests fail. I also don't see how getting the performance output in the output unconditionally is not making the test fail.
Feb 15 2017
Just updating with current state. after rebasing I now get some random segfaults which need to be figured out. dlltool is also way too slow so a custom import lib writer needs to be written and will leverage that to write a custom loader to solve the remaining issue of how to correctly handle const data issue introduced by GHC's dynamic linking not having been designed to work cross platform.
- T5987: rebased.
- T5987: fixing after rebase
- T5987: Fixes after rebase.
- T5987: reverted submodules.
- DynLib: Fix ghc-cabal build errors and rts build error.
- T5987: Reworking DLL building code.
- T5987: Fix failure.
- T5987: turn off lazy loading.
- Dyn: remove assert code and other werr issues.
- Disable CoreToStg asserts for DynWay for now.
- Update submodules.
- Shared: added gen-dll
- Gen-Dll: Added better argument parsing
- Calling Win32 args parser
- GenDll: Fixed gen-dll I/O
- Dll: Enable dynamic-too on Windows.
- Fix some more rebase screwiness
- Remove more dllsplit tstuff again
- Fix execProc.
- Disable CoreToStg warnings completely.
- Fix -Werror
- Correct ar script.
- Dyn: disable import lib creation.
- fix compile.
- Inlined dependency resolving into addDllHandler
- Rebased on master
arc seems to currently be broken, so I can't update the patch. Unless someone knows a way to do it without arc?
Feb 14 2017
Feb 12 2017
Thanks @bollu !
Thanks @bollu! Just some minor comments.
Feb 7 2017
Feb 6 2017
Feb 5 2017
- use handle instead of filename in duplicate check
So without the normalization we get a slightly different result because now the system dll's names won't match.