On 02/05/2014 00:46, Edward Kmett wrote:
With the old custom linker we weren't able to get our custom MPFR linked
in properly on all platforms for use in ghci.
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.
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.
I think this is the whole problem. Normally you would use an external
dynamically-linked MPFR, but because you need custom changes to it, you
have a local version of it which needs to get linked with your Haskell
code. Presumably you have to arrange to build it with -fPIC somehow?
If you have C/C++ code in the same library as your Haskell code, then
dynamic linking will work better (at least on OS X, where they tend to
change the linking semantics more often than ELF, and we have to
duplicate that in our linker). This is a good point, but rather than
try to fix that I would instead look at whether you could build your
custom MPFR as a shared library, which should work fine regardless of
whether GHCi is dynamically linked or not. The only issue should be
passing the right -rpath so that executables can find your custom MPFR,
which is something we already do for dynamic linking.
Cheers,
Simon
Switching to the system dynamic linker fo ghci seems to have resolved
all of that effortlessly.
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.
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.
-Edward
On Thu, May 1, 2014 at 5:30 PM, Simon Marlow <marlo...@gmail.com
<mailto:marlo...@gmail.com>> wrote:
On 01/05/14 15:27, Edward Kmett wrote:
Figured I'd make one case for dynamic linking:
https://github.com/ekmett/__rounded
<https://github.com/ekmett/rounded>
Dynamic linking is finally enabling us to build a version of MPFR
bindings for Haskell for scientific/high precision computing
with 7.8. I
would really hate to lose it after all of these years trying to
get it
work, as I have a rather large edifice being built atop that
platform.
We tried and failed due to limitations of the old linker for
almost 3 years.
I understand the issues with MPFR. But how is dynamic linking helping?
That said, -dynamic-too seems to cause me all sorts of problems
elsewhere. ^C'ing out of a build and restarting it will often
make a .o
but lose the .dyn_o, leading to GHC + cabal getting confused and
refusing to build until I clean. This hits me several times a day.
We should fix this (or at least make it a lot less likely). Is
there a ticket?
Cheers,
Simon
-Edward
On Thu, May 1, 2014 at 3:29 AM, Simon Peyton Jones
<simo...@microsoft.com <mailto:simo...@microsoft.com>
<mailto:simo...@microsoft.com <mailto:simo...@microsoft.com>>__>
wrote:
| Dynamic linking has been a huge headache in GHC, and it's not
clear that
| it's an overall improvement compared with the static
linker. Now that
| 7.8 is out of the way, it's time to have a conversation about
whether we
| want to do dynamic linking again for 7.10, or revert to
static
linking.
I echo this. Dynamic linking has had many un-anticipated
costs and
it is still very far from sorted out. It originally felt
like a
Fantastic Idea to give up our own linker and adopt the system
linker, but it now feels to me like a black hole, endlessly
sucking
effort and increasing complexity.
My viewpoint is highly un-informed about details; I just
watch the
traffic going by. And of course it does have benefits that
doubtless generate less traffic.
Simon
|
|
|
| >
| > On Tue, Apr 29, 2014 at 6:13 PM, Simon Peyton Jones
| > <simo...@microsoft.com <mailto:simo...@microsoft.com>
<mailto:simo...@microsoft.com <mailto:simo...@microsoft.com>>
<mailto:simo...@microsoft.com
<mailto:simo...@microsoft.com> <mailto:simo...@microsoft.com
<mailto:simo...@microsoft.com>>__>> wrote:
| >
| > As Austin has told us, there's a draft of the *GHC
Status Report
| for
| > the HCAR*, here:____
| >
| >
https://ghc.haskell.org/trac/__ghc/wiki/Status/May14____
<https://ghc.haskell.org/trac/ghc/wiki/Status/May14____>
| >
| > Have we missed out something you have been working
hard on? Do
| > take a moment to add a bullet in an appropriate
place (it's a
| > wiki). I'd like to be sure that we are giving
credit to all the
| > appropriate people, so please help us fix that too.
GHC is
a team
| > effort.____
| >
| > Deadline is 1 May I think.____
| >
| > Thanks____
| >
| > Simon____
| >
| > __ __
| >
| >
| > _________________________________________________
| > ghc-devs mailing list
| > ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>
<mailto:ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>>
<mailto:ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>
<mailto:ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>>>
| > http://www.haskell.org/__mailman/listinfo/ghc-devs
<http://www.haskell.org/mailman/listinfo/ghc-devs>
| >
| >
| >
| >
| > _________________________________________________
| > ghc-devs mailing list
| > ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>
<mailto:ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>>
| > http://www.haskell.org/__mailman/listinfo/ghc-devs
<http://www.haskell.org/mailman/listinfo/ghc-devs>
| >
_________________________________________________
ghc-devs mailing list
ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>
<mailto:ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>>
http://www.haskell.org/__mailman/listinfo/ghc-devs
<http://www.haskell.org/mailman/listinfo/ghc-devs>
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
