- User Since
- Nov 5 2014, 3:01 PM (119 w, 6 d)
Mon, Feb 20
Ah, that looks better...
- fix linux build
It is possible, arc was being particularly difficult that day. But according to my tree
Sun, Feb 19
As can be seen https://phabricator.haskell.org/harbormaster/build/21193/
- fix linux build
https://phabricator.haskell.org/B14010 testsuite build
Sat, Feb 18
Thu, Feb 16
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.
Wed, Feb 15
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?
Tue, Feb 14
Sun, Feb 12
Thanks @bollu !
Thanks @bollu! Just some minor comments.
Tue, Feb 7
Mon, Feb 6
Sun, Feb 5
- 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.
- Second part of plit
Split into this and D3082
@simonmar Sorry, didn't see that you commented here. I'll split up the patch.
- Remove old code that isn't needed.
After the update the behavior is now more consistent with the linux one
- slight refactoring to be able to call dependencies resolving manually.'
Wed, Feb 1
@erikd I personally think so, the use case I had in mind would have me call the methods from a C stub linked into the executable. It would be non-ideal to have to go through the haskell interface to do this. Ofcourse it's C, so I don't really need the header, so I'll leave it up to you :)
This looks fine to me, Just have one question,
@simonpj I believe you currently use this to ignore test data? Maybe instead add it to .git/info/exclude?
This would be local and would have to be added in each clone but it won't give surprising behaviour to those not expecting it.
Tue, Jan 31
Sorry, this patch comes from a much larger patch which I split up and forgot to accept the new test output.
Sat, Jan 28
- Added mingw fft output
- Add missing function.
- Add notes
Fri, Jan 27
Oh... git blame... the irony.. I'm the one who added the ifdef to begin with..
oh, I didn't know about that ifdef in ghcilink003, that has been fixed a while ago in 8.0.1 with support for import libraries. just -lstdc++ is needed now. This will find libstdc++.dll.a which then resolves to libstdc++-6.dll on use. What this patch does is also bring into scope libgcc. Say if that test used a symbol from libgcc without adding -lgcc_eh_... it would have worked compiled before but GHCi wouldn't have worked. Now it would work both with GHC and GHCi.
Oops, when I split the patch up into little chunks i must have missed something here. I'll fix the build.
Thu, Jan 26
Yes, the else is everything else. e.g. linux :)
It requires msys, just because the shell detection is done using msys and because of the unix tools used. tr, sed, diff and perl. and of course make.
-lstdc++ won't break in the future, but yeah I'm describing the opposite.
- Add retry loop.
- Fix retry loop.
Wed, Jan 25
@bgamari can you update the submodule to 716c9a3e97611aea3a0a907ba80fe9c11e1afc7f for me? That would fix the build.
I've updated the CI to build with -Werror to prevent this in the future. Still need to setup a reverse proxy before external users can see the error though.
Hmm, It seems that this is generating a warning that my CI for Win32 didn't catch.
Should add the same build flags as validate to prevent this...
Tue, Jan 24
Ah ok thanks, I had forgotten I moved try. So much changed in this release...
Jan 22 2017
- Just use a retry loop.