The problems I was seeing with ghci prior to 7.8 are similar to the
ones reported by Edward Kmett above: addresses were mapped
incorrectly. This was compounded by the fact that the
library used was not thread-safe, so there were two issues,
which may explain why -fno-ghci-sandbox did not help.
On
On 2014-04-29 at 12:27:38 +0200, Simon Marlow wrote:
[...]
I think that's fine. As Simon points out, we already have lagging
repo functionality in the form of the submodule links, so the repo on
git.haskell.org can be a pure mirror.
Just so I get this right, does pure mirror here mean that
On 02/05/2014 14:28, Edward Kmett wrote:
Perhaps. We actually tried that originally, but had issues about
where and how to get cabal to place it. We'd need it to go somewhere
installed rather than the local build dir lest it not be there when
we go to use the lib, but IIRC, cabal
I may have to dig to find an example, but when I last checked it seemed
that c++ libraries would load fine, but there was a problem with static
initializers not getting called, when loading from ghci, so if your c++
library needed them then you'd have problems.
An earlier version of the MPFR
Richard,
I've posted this problem as #9047
(https://ghc.haskell.org/trac/ghc/ticket/9047), but I have no
information to help you -- sorry!
Thanks anyway.
--Kazu
___
ghc-devs mailing list
ghc-devs@haskell.org
I downloaded HEAD and placed DYNAMIC_GHC_PROGRAMS=NO in the quick
section of mk/build.mk (with BuildFlavour = quick), and set
DYNAMIC_GHC_PROGRAMS=NO
in my environment before running configure (just to be sure!). Near
the end of the build
I saw some messages like Warning: vectorization failure,
On May 2, 2014, at 9:05 AM, Simon Marlow marlo...@gmail.com wrote:
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
On Fri, May 2, 2014 at 10:19 AM, Edward Kmett ekm...@gmail.com wrote:
I may have to dig to find an example, but when I last checked it seemed
that c++ libraries would load fine, but there was a problem with static
initializers not getting called, when loading from ghci, so if your c++
library
| Is -O required for optimization across module bounds?
Yes, without -O GHC doesn’t put inlinings into interface files, so an importing
module can't see them. Use -fno-omit-interface-pragmas to tell GHC to put the
stuff in the interface file regardless.
| Also, since I really want a certain
On 02/05/14 18:19, Edward Kmett wrote:
I may have to dig to find an example, but when I last checked it seemed
that c++ libraries would load fine, but there was a problem with static
initializers not getting called, when loading from ghci, so if your c++
library needed them then you'd have
Can you give me a quick summary of how to reproduce the problem? (not
including the GHC build steps)
Cheers,
Simon
On 02/05/14 18:18, Dominick Samperi wrote:
I downloaded HEAD and placed DYNAMIC_GHC_PROGRAMS=NO in the quick
section of mk/build.mk (with BuildFlavour = quick), and set
On 02/05/2014 01:09, Dominick Samperi wrote:
If I understand your last comment correctly linking to libR should
continue to work, even if you revert to static linking of Haskell compiled
code via RTS linker. Since you say this is the way things have always
been, perhaps the real explanation for
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
13 matches
Mail list logo
