Hi all,
GHC HEAD now has support for using dynamic libraries by default (and in
particular, using dynamic libraries and the system linker in GHCi) for a
number of platforms.
This has some advantages and some disadvantages, so we need to make a
decision about what we want to do in GHC 7.8. There
Somebody claiming to be Ian Lynagh wrote:
GHC HEAD now has support for using dynamic libraries by default (and in
particular, using dynamic libraries and the system linker in GHCi) for a
number of platforms.
The various issues are described in a wiki page here:
On Tue, Nov 27, 2012 at 10:22:12AM -0500, Stephen Paul Weber wrote:
Somebody claiming to be Ian Lynagh wrote:
GHC HEAD now has support for using dynamic libraries by default (and in
particular, using dynamic libraries and the system linker in GHCi) for a
number of platforms.
The various
Somebody claiming to be Ian Lynagh wrote:
On Tue, Nov 27, 2012 at 10:22:12AM -0500, Stephen Paul Weber wrote:
IIRC, one of the problems with dynamic linking in GHC is that when
the GHC version is different, the ABI can often be different enough
to making such shared libraries incompatible with
On Tue, Nov 27, 2012 at 12:07:34PM -0500, Stephen Paul Weber wrote:
Somebody claiming to be Ian Lynagh wrote:
On Tue, Nov 27, 2012 at 10:22:12AM -0500, Stephen Paul Weber wrote:
IIRC, one of the problems with dynamic linking in GHC is that when
the GHC version is different, the ABI can often
On Tue, Nov 27, 2012 at 08:38:21PM +0100, Matthias Kilian wrote:
On Tue, Nov 27, 2012 at 02:52:48PM +, Ian Lynagh wrote:
The various issues are described in a wiki page here:
http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault
If you have a few minutes to read it then we'd
I don't totally understand how ghci loading would work. I assume that
for external packages it will go load x.so instead of x.a, but what
about local modules? I assume ghc -c is still going to produce .o
files, so does that mean ghci will have to interpret all local moules?
If so, is there a
Hi,
On Tue, Nov 27, 2012 at 08:15:59PM +, Ian Lynagh wrote:
Regarding Question 7 (enable dynamic by default on other platforms)
and OpenBSD: as long as it's easy to disable it again, I'll be happy
with *any* decision.
It will be easy to turn it off, but depending on the platform we
Hi,
Am Dienstag, den 27.11.2012, 14:52 + schrieb Ian Lynagh:
The various issues are described in a wiki page here:
http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault
If you have a few minutes to read it then we'd be glad to hear your
feedback, to help us in making our
On Tue, Nov 27, 2012 at 01:34:59PM -0800, Evan Laforge wrote:
I don't totally understand how ghci loading would work. I assume that
for external packages it will go load x.so instead of x.a, but what
about local modules? I assume ghc -c is still going to produce .o
files, so does that mean
On Tue, Nov 27, 2012 at 3:52 PM, Ian Lynagh i...@well-typed.com wrote:
This has some advantages and some disadvantages, so we need to make a
decision about what we want to do in GHC 7.8.
When I built my CLI app with dynamic linking, the time to run and complete
a command went from 20ms to
That was with GHC 7.4.1, I should add. I didn't measure overall performance
difference, only the time to finish a command-line invocation.
On Wed, Nov 28, 2012 at 3:11 AM, dag.odenh...@gmail.com
dag.odenh...@gmail.com wrote:
On Tue, Nov 27, 2012 at 3:52 PM, Ian Lynagh i...@well-typed.com
And on 32 bit Linux, which apparently is known to suffer from dynamic...
Though from 20ms to 100ms is more than 30% penalty.
On Wed, Nov 28, 2012 at 3:16 AM, dag.odenh...@gmail.com
dag.odenh...@gmail.com wrote:
That was with GHC 7.4.1, I should add. I didn't measure overall
performance
On Wed, 2012-11-28 at 00:28 +0100, Joachim Breitner wrote:
Am Dienstag, den 27.11.2012, 14:52 + schrieb Ian Lynagh:
The various issues are described in a wiki page here:
http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault
If you have a few minutes to read it then we'd be
Hi,
GHC HEAD now has support for using dynamic libraries by default (and in
particular, using dynamic libraries and the system linker in GHCi) for a
number of platforms.
I am very happy to hear this news.
I have long been a quiet proponent for defaulting ghc and Cabal to
shared libraries and
On 28 November 2012 03:02, Ian Lynagh i...@well-typed.com wrote:
We actually have half a plan to fix this, so that a single compilation
would build both static and dynamic libraries. Most of the work
(parsing, type checking, optimising) can be shared; it's just the
codegen phase that needs to
On 28 November 2012 08:28, Joachim Breitner nome...@debian.org wrote:
Open question: What should GHC on Debian do when building binaries,
given that all libraries are likely available in both ways – shared or
static. Shared means that all locally built binaries (e.g. xmonad!) will
suddenly
17 matches
Mail list logo
