<div dir="ltr">With the old custom linker we weren't able to get our custom MPFR linked in properly on all platforms for use in ghci. <div><br></div><div>On Macs we ran into some rather interesting problems. We could get it to work for actual executables, but ghci would segfault with stuff resolved to clearly wrong addresses. If I recall correctly it may have been some kind of MachO symbol type that wasn't being resolved properly by the custom GHC linker, perhaps? We chased after it off and on for a long time to no avail. </div>
<div><div><br></div><div>It was complicated a great deal by having to build their library and merge it directly into ours, because we couldn't use system MPFR, due to the issues with the GHC garbage collector hooks into GMP.<div>
<div><div><br></div><div>Switching to the system dynamic linker fo ghci seems to have resolved all of that effortlessly.</div><div><br></div><div>Dan Peebles has been talking to the MPFR folks to see if we can get them to expose enough information about the 'hidden' allocations they use that we can make them visible to GHC or have them do what our local fix does and avoid using the MPFR allocator for their hidden constant cache. </div>
<div><br></div><div>If they do that then we can actually link to the library like normal rather than link it in directly, but it isn't clear to me what would happen even with those hooks if we rolled back to something like the old custom linker.</div>
<div><br></div><div>-Edward</div></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 1, 2014 at 5:30 PM, Simon Marlow <span dir="ltr"><<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 01/05/14 15:27, Edward Kmett wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Figured I'd make one case for dynamic linking:<br>
<br>
<a href="https://github.com/ekmett/rounded" target="_blank">https://github.com/ekmett/<u></u>rounded</a><br>
<br>
Dynamic linking is finally enabling us to build a version of MPFR<br>
bindings for Haskell for scientific/high precision computing with 7.8. I<br>
would really hate to lose it after all of these years trying to get it<br>
work, as I have a rather large edifice being built atop that platform.<br>
We tried and failed due to limitations of the old linker for almost 3 years.<br>
</blockquote>
<br></div>
I understand the issues with MPFR. But how is dynamic linking helping?<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That said, -dynamic-too seems to cause me all sorts of problems<br>
elsewhere. ^C'ing out of a build and restarting it will often make a .o<br>
but lose the .dyn_o, leading to GHC + cabal getting confused and<br>
refusing to build until I clean. This hits me several times a day.<br>
</blockquote>
<br></div>
We should fix this (or at least make it a lot less likely). Is there a ticket?<br>
<br>
Cheers,<br>
Simon<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
-Edward<br>
<br>
<br>
On Thu, May 1, 2014 at 3:29 AM, Simon Peyton Jones<br></div><div class="">
<<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a> <mailto:<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>><u></u>> wrote:<br>
<br>
| Dynamic linking has been a huge headache in GHC, and it's not<br>
clear that<br>
| it's an overall improvement compared with the static linker. Now that<br>
| 7.8 is out of the way, it's time to have a conversation about<br>
whether we<br>
| want to do dynamic linking again for 7.10, or revert to static<br>
linking.<br>
<br>
I echo this. Dynamic linking has had many un-anticipated costs and<br>
it is still very far from sorted out. It originally felt like a<br>
Fantastic Idea to give up our own linker and adopt the system<br>
linker, but it now feels to me like a black hole, endlessly sucking<br>
effort and increasing complexity.<br>
<br>
My viewpoint is highly un-informed about details; I just watch the<br>
traffic going by. And of course it does have benefits that<br>
doubtless generate less traffic.<br>
<br>
Simon<br>
<br>
|<br>
|<br>
|<br>
| ><br>
| > On Tue, Apr 29, 2014 at 6:13 PM, Simon Peyton Jones<br>
| > <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a> <mailto:<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>><br></div><div class="">
<mailto:<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a> <mailto:<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>><u></u>>> wrote:<br>
| ><br>
| > As Austin has told us, there's a draft of the *GHC Status Report<br>
| for<br>
| > the HCAR*, here:____<br>
| ><br>
| > <a href="https://ghc.haskell.org/trac/ghc/wiki/Status/May14____" target="_blank">https://ghc.haskell.org/trac/<u></u>ghc/wiki/Status/May14____</a><br>
| ><br>
| > Have we missed out something you have been working hard on? Do<br>
| > take a moment to add a bullet in an appropriate place (it's a<br>
| > wiki). I'd like to be sure that we are giving credit to all the<br>
| > appropriate people, so please help us fix that too. GHC is<br>
a team<br>
| > effort.____<br>
| ><br>
| > Deadline is 1 May I think.____<br>
| ><br>
| > Thanks____<br>
| ><br>
| > Simon____<br>
| ><br>
| > __ __<br>
| ><br>
| ><br>
| > ______________________________<u></u>_________________<br>
| > ghc-devs mailing list<br>
| > <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a> <mailto:<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>><br></div>
<mailto:<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a> <mailto:<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>>><div class=""><br>
| > <a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/ghc-devs</a><br>
| ><br>
| ><br>
| ><br>
| ><br>
| > ______________________________<u></u>_________________<br>
| > ghc-devs mailing list<br>
| > <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a> <mailto:<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>><br>
| > <a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/ghc-devs</a><br>
| ><br>
______________________________<u></u>_________________<br>
ghc-devs mailing list<br></div>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a> <mailto:<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/ghc-devs</a><br>
<br>
<br>
</blockquote>
<br>
</blockquote></div><br></div>