User Details
- User Since
- Aug 1 2018, 9:55 AM (71 w, 2 d)
Oct 22 2019
Oct 2 2019
Jul 8 2019
Jul 2 2019
Jun 13 2019
Jun 10 2019
Jun 9 2019
Jun 4 2019
May 29 2019
May 25 2019
May 24 2019
May 23 2019
May 21 2019
May 20 2019
May 10 2019
Apr 14 2019
Apr 2 2019
Mar 15 2019
Mar 5 2019
Mar 4 2019
Jan 25 2019
Looking at the make build system, the UseLibFFIForAdjustors variable is only used to toggle cLibFFI in Config.hs files, and also in compiler/ghc.mk to set the USE_LIBFFI_FOR_ADJUSTORS flag when compiling the rts:
@bgamari, last we spoke it was unclear why this would work to limit linking agains ffi as per my previous comment:
Jan 8 2019
Dec 20 2018
This depends on this Haddock PR: https://github.com/haskell/haddock/pull/984
- Included all changes.
Rebase, resolve conflicts, and fix build.
@mpickering Ok, I'll do the rebase now.
Dec 19 2018
Dec 18 2018
Hello, sorry for the delay here. I can't seem to build this patch and am seeing merge conflicts. Can you please rebase on master, and resolve any merge conflicts.
Dec 17 2018
Keep in mind that the dynamic ghc build has been disabled in D5430 due to the failing hadrian build.
Dec 11 2018
The build failure in question is failing to find libffi when building the default flavour on x86_64 with no system wide libffi installed. The command that fails is when linking the ghc binary. The make build system links the ghc binary with -lffi. On that grounds I would say that D5427 will not solve this issue that this patch does.
There seems to be some logic using -l$$(LIBFFI_NAME) in rts/ghc.mk. configure.ac also seems to set the default value of the ffi flag by doing AC_SUBST([CabalHaveLibffi],[False]) or AC_SUBST([CabalHaveLibffi],[True]).
Im confused: setting the ffi flag *enables* linking with ffi. So if I understand correctly, this can only serve to *increase* the cases where we link with ffi. I'm trying to find the relevant logic in the make build system now.
Funny enough, I just came accross this in the make build system rts/ghc.mk:127:
Dec 10 2018
I've tested locally using a nix environment where the Hadrian default build fails on master. With this patch I successfully built and ran tests for flavours: default, perf, quick, and quickest.
After speaking with Alp, we've decided it is safer to simply revert the dynamic linking changes: D5430. This should fix the Hadrian build while a hack free solution can be found.
Dec 9 2018
Rebase
You're absolutely right @bgamari, this situation is not ideal, but I do fully intend to continue work on this. The Hadrian build is broken and the correct solution seems non-trivial, hence I saw this hacky solution as somewhat justified.
Dec 7 2018
This fixes the build on CircleCI: https://gitlab.staging.haskell.org/DavidEichmann/ghc/-/jobs/904. Using Alp's nix environment I was able to recreate the build failure by building the default flavour. In the same environment with this patch build succeeds and I have run the tests in the perf and default flavours. I still see the drop in test failures the we expect from dynamically linking ghc.
Dec 4 2018
Dec 2 2018
There is a similar issue on linux where we link the system ffi instead of the local one. This fails e.g. on CircleCI as ld cannot find the ffi library. I don't know if this is related to the OSX failure, but I'll continue investigating this on linux.
Nov 30 2018
Included too many changes in the last diff.
Converting check_output() result to bool is confusing and in this case is wrong. Comparing to byte string literal instead.
Nov 29 2018
Hello, thanks for fixing that, great work! I see you also added a test which is always appreciated. Before I accept:
- I still think throwing an exception is more valid. I.e. replace loadSrcInterface_maybe with loadSrcInterface (this change would also make the code a bit simpler). If you're not sure why, do ask. If you're convinced otherwise, I'm not gonna fight you on it.
- The changes in .gitmodules should be reverted (as a rule of thumb, I'll only accept if I think it's ready to merge as is).
- You can easily fix this without breaking your build by, first pushing your changes git push, then re-cloning ghc using git clone git://git.haskell.org/ghc --recurse-submodules (if you need help with this feel free to contact me on IRC at freenode #haskell my handle is DavidEichmann).
This was merged as part of D5312.
Build ghc with -fPIC -dynamic if RTS has a dynamic way.
Don't link executables with -shared -dynload deploy.
These changes are all in hadrian/src/Settings/Builders/Ghc.hs
Nov 28 2018
Nov 27 2018
- Use git status instead of rev-parse
- Fix logic to call Perf.append_perf_stat() only if canGitStatus.
- Improve error message.
Nov 26 2018
@osa1 We use git notes to get the baseline performance numbers and to save the new numbers. Here we only skip performance tests if we both cannot get a baseline (and hence can't tell if tests pass or fail) nor have a way to save the results.
- Replace is_git_repo with can_git_status.
Nov 23 2018
Nov 22 2018
Validate now passes locally for me.
- Fix T4437 by removing DerivingVia from expectedGhcOnlyExtensions. Update comment in GHC.Magic.
Nov 21 2018
- Bump Cabal, bytestring, containers, and text.
- Fix unused matches error.
- Remove unused imprt after rebase.
- Fix GHC.Magic validation errors.
- Correct assignment of hasMetricsFile.
Nov 20 2018
There seems to be some errors when I validate locally. I'm working on this now.
Nov 19 2018
- Fix unused matches error.
- Bump Cabal, bytestring, containers, and text.
Nov 13 2018
Hi @alanasp, Have you managed to have a look at the issue since we last spoke? It would be great to see this to completion. I appreciate that a significant amount of effort has already gone into this patch. If you're short on time/resources, please let me know and I will investigate this further.
Nov 12 2018
We'll likely need to bump Cabal again soon, but this at least gets ghc to build with Cabal 2.5.0.0.
Fix comment.
Nov 8 2018
More commit message fiddling (I'm not sure how arcanist handles this).
Update commit message explaining why ieLWrappedName change was reverted.
Nov 5 2018
Oct 31 2018
Looks good to me.