<div dir="ltr">Come to think of it the static initializer we were trying _was_ being glued into the haskell package, not the external lib where it might have actually worked so that may be where my confusion came in.<div><br>
</div><div>-Edward</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 2, 2014 at 3:44 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 02/05/14 18:19, Edward Kmett wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I may have to dig to find an example, but when I last checked it seemed<br>
that c++ libraries would load fine, but there was a problem with static<br>
initializers not getting called, when loading from ghci, so if your c++<br>
library needed them then you'd have problems.<br>
</blockquote>
<br></div>
I think we're getting confused here. External C++ libraries are, and always have been, loaded by the system linker, regardless of whether GHCi itself is dynamically linked. So there's no difference in 7.8 with respect to how external C++ code is loaded.<br>
<br>
However, if you link the C++ code into the same library as the Haskell code as you're doing with MPFR, then of course there is a difference (let's call that *internal* C++ code, for want of a better name). I think that's a rare case (I understand why you need to do it), and most people should be linking their C++ code via separate shared libraries.<div class="">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
An earlier version of the MPFR hackery used a static initializer to<br>
replace the GHC garbage collection hook for GMP with one that played<br>
evil games to figure out if it was being called from the MPFR constant<br>
cache.<br>
<br>
That initialized and loaded fine from ghc, but not from ghci. Our static<br>
initializer was never being called, despite the library being loaded.<br>
<br>
If your C++ practices there forbid static initializers -- some places do<br>
-- that may be why you aren't seeing the issue.<br>
</blockquote>
<br></div>
Absolutely not, we're drowning in static initialisers :)<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 Fri, May 2, 2014 at 9:47 AM, Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a><br></div><div><div class="h5">
<mailto:<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>>> wrote:<br>
<br>
On 02/05/2014 14:28, Edward Kmett wrote:<br>
> Perhaps. We actually tried that originally, but had issues about<br>
> where and how to get cabal to place it. We'd need it to go somewhere<br>
> installed rather than the local build dir lest it not be there when<br>
> we go to use the lib, but IIRC, cabal couldn't/wouldn't tell me where<br>
> it was putting the final installed version and then there is the<br>
> issue of the local in place runs vs. post cabal install runs and<br>
> referencing that dir from subsequent projects. If we want a<br>
> transparent ’cabal install rounded` It isn't clear to me how to get<br>
> there down this path, but it is entirely possible I just missed<br>
> something obvious.<br>
><br>
> MPFR/rounded was just an off the cuff example. Another place where<br>
> the dynamic linker really helps is external c++ libraries which<br>
> should now actually get all of their initializers called in the right<br>
> order when launched from ghci.<br>
<br>
External C++ libraries work just fine with the statically linked GHCi -<br>
it uses the system linker to load them, and all the initalizers get<br>
called, in the right order, as they should. So this is where I'm<br>
confused about what the problems actually are - there seems to be this<br>
perception that GHCi didn't work with external C++ code, but as far as I<br>
know it works just fine (indeed we're doing it a lot at Facebook, so<br>
there's at least an existence proof that depending on a non-trivial<br>
amount of external C++ with a statically-linked GHCi can work).<br>
<br>
Cheers,<br>
Simon<br>
<br>
<br>
><br>
><br>
>> Cheers,<br>
>> Simon<br>
>><br>
>>> Switching to the system dynamic linker fo ghci seems to have<br>
resolved<br>
>>> all of that effortlessly.<br>
>>><br>
>>> Dan Peebles has been talking to the MPFR folks to see if we can<br>
get them<br>
>>> to expose enough information about the 'hidden' allocations<br>
they use<br>
>>> that we can make them visible to GHC or have them do what our<br>
local fix<br>
>>> does and avoid using the MPFR allocator for their hidden<br>
constant cache.<br>
>>><br>
>>> If they do that then we can actually link to the library like<br>
normal<br>
>>> rather than link it in directly, but it isn't clear to me what<br>
would<br>
>>> happen even with those hooks if we rolled back to something<br>
like the old<br>
>>> custom linker.<br>
>>><br>
>>> -Edward<br>
>>><br>
>>><br>
>>> On Thu, May 1, 2014 at 5:30 PM, Simon Marlow<br>
<<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a> <mailto:<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>><br></div></div><div><div class="h5">
>>> <mailto:<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a> <mailto:<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>>>> wrote:<br>
>>><br>
>>> On 01/05/14 15:27, Edward Kmett wrote:<br>
>>><br>
>>> 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>
>>> <<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<br>
version of MPFR<br>
>>> bindings for Haskell for scientific/high precision<br>
computing<br>
>>> with 7.8. I<br>
>>> would really hate to lose it after all of these years<br>
trying to<br>
>>> get it<br>
>>> work, as I have a rather large edifice being built atop<br>
that<br>
>>> platform.<br>
>>> We tried and failed due to limitations of the old<br>
linker for<br>
>>> almost 3 years.<br>
>>><br>
>>><br>
>>> I understand the issues with MPFR. But how is dynamic<br>
linking helping?<br>
>>><br>
>>><br>
>>> That said, -dynamic-too seems to cause me all sorts of<br>
problems<br>
>>> elsewhere. ^C'ing out of a build and restarting it will<br>
often<br>
>>> make a .o<br>
>>> but lose the .dyn_o, leading to GHC + cabal getting<br>
confused and<br>
>>> refusing to build until I clean. This hits me several<br>
times a day.<br>
>>><br>
>>><br>
>>> We should fix this (or at least make it a lot less likely). Is<br>
>>> there a ticket?<br>
>>><br>
>>> Cheers,<br>
>>> Simon<br>
>>><br>
>>><br>
>>> -Edward<br>
>>><br>
>>><br>
>>> On Thu, May 1, 2014 at 3:29 AM, 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>
<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>><br></div></div><div>
<div class="h5">
>>> <mailto:<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a><br>
<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><br>
<mailto:<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>><u></u>>>__><br>
>>> wrote:<br>
>>><br>
>>> | Dynamic linking has been a huge headache in GHC,<br>
and it's not<br>
>>> clear that<br>
>>> | it's an overall improvement compared with the static<br>
>>> linker. Now that<br>
>>> | 7.8 is out of the way, it's time to have a<br>
conversation about<br>
>>> whether we<br>
>>> | want to do dynamic linking again for 7.10, or<br>
revert to<br>
>>> static<br>
>>> linking.<br>
>>><br>
>>> I echo this. Dynamic linking has had many<br>
un-anticipated<br>
>>> costs and<br>
>>> it is still very far from sorted out. It<br>
originally felt<br>
>>> like a<br>
>>> Fantastic Idea to give up our own linker and adopt<br>
the system<br>
>>> linker, but it now feels to me like a black hole,<br>
endlessly<br>
>>> sucking<br>
>>> effort and increasing complexity.<br>
>>><br>
>>> My viewpoint is highly un-informed about details;<br>
I just<br>
>>> watch the<br>
>>> traffic going by. And of course it does have<br>
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<br>
Jones<br>
>>> | > <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a><br>
<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><br>
<mailto:<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>><u></u>><br>
>>> <mailto:<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a><br>
<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><br>
<mailto:<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>><u></u>>><br>
>>> <mailto:<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a><br>
<mailto:<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>><br>
>>> <mailto:<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a><br>
<mailto:<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>><u></u>> <mailto:<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a><br>
<mailto:<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>><br>
>>> <mailto:<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a><br>
<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<br>
the *GHC<br>
>>> Status Report<br>
>>> | for<br>
>>> | > the HCAR*, here:____<br>
>>> | ><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>
>>> <<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<br>
been working<br>
>>> hard on? Do<br>
>>> | > take a moment to add a bullet in an<br>
appropriate<br>
>>> place (it's a<br>
>>> | > wiki). I'd like to be sure that we are giving<br>
>>> credit to all the<br>
>>> | > appropriate people, so please help us fix<br>
that too.<br>
>>> 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>
>>> | ><br>
______________________________<u></u>___________________<br>
>>> | > ghc-devs mailing list<br>
>>> | > <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<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><br>
<mailto:<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>>><br>
>>> <mailto:<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<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><br>
<mailto:<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>>><u></u>><br>
>>> <mailto:<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<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><br>
<mailto:<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>>><br>
>>> <mailto:<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<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><br>
<mailto:<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>>><u></u>>><br>
>>><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>
>>> <<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><br>
<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><br>
<mailto:<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>>><br>
>>> <mailto:<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<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><br>
<mailto:<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>>><u></u>><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>
>>> <<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>
>>> <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>
<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>>><br>
>>> <mailto:<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<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><br>
<mailto:<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>>><u></u>><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>
>>> <<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>
<br>
<br>
</div></div></blockquote>
<br>
</blockquote></div><br></div>