Dynamic libraries by default and GHC 7.8

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
61 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Dynamic libraries by default and GHC 7.8

Ian Lynagh-2

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 are also some policy
questions we need to answer about how Cabal will work with a GHC that
uses dynamic libraries by default. We would like to make these as soon
as possible, so that GHC 7.6.2 can ship with a Cabal that works
correctly.

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 decisions


Thanks
Ian
--
Ian Lynagh, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic libraries by default and GHC 7.8

Stephen Paul Weber
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:
>    http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault

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 each other / binaries made on different
GHCs.  This makes distribution a potential nightmare (where you have to
package all the *.so files and send them along with your binary, which is
essentially the same as static linking, but more pain).  Is this no longer
the case, or am I completely misremembering this?

Also, you say "for a number of platforms" and that wiki page says
"Currently, we don't know how to do dynamic-by-default on Windows in
a satisfactory way."  So I assume Windows is not one of the platforms that
would be seeing this change?

--
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic libraries by default and GHC 7.8

Ian Lynagh-2
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 issues are described in a wiki page here:
> >   http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault
>
> 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 each other /
> binaries made on different GHCs.  This makes distribution a
> potential nightmare (where you have to package all the *.so files
> and send them along with your binary, which is essentially the same
> as static linking, but more pain).  Is this no longer the case, or
> am I completely misremembering this?

That is still the case. However, if you want to distribute binaries then
you will still be able to build with -static if you don't want to have
ot bundle a load of DLLs. It's only the default that will change.

> Also, you say "for a number of platforms" and that wiki page says
> "Currently, we don't know how to do dynamic-by-default on Windows in
> a satisfactory way."  So I assume Windows is not one of the
> platforms that would be seeing this change?

We would love for Windows to be one of the platforms, but currently we
can't do it on Windows. So unless that changes, Windows will not be one
of the platforms, correct.


Thanks
Ian


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic libraries by default and GHC 7.8

Stephen Paul Weber
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 each other /
>> binaries made on different GHCs.  This makes distribution a
>> potential nightmare (where you have to package all the *.so files
>> and send them along with your binary, which is essentially the same
>> as static linking, but more pain).
>
>That is still the case. However, if you want to distribute binaries then
>you will still be able to build with -static if you don't want to have
>ot bundle a load of DLLs. It's only the default that will change.
If the default changes, though, that would mean that before distribution
I would have to re-build all my cabal packages with -static?  And if
I change my default so that cabal builds with -static GHCI would no longer
work for me?

--
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic libraries by default and GHC 7.8

Ian Lynagh-2
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 be different enough
> >>to making such shared libraries incompatible with each other /
> >>binaries made on different GHCs.  This makes distribution a
> >>potential nightmare (where you have to package all the *.so files
> >>and send them along with your binary, which is essentially the same
> >>as static linking, but more pain).
> >
> >That is still the case. However, if you want to distribute binaries then
> >you will still be able to build with -static if you don't want to have
> >ot bundle a load of DLLs. It's only the default that will change.
>
> If the default changes, though, that would mean that before
> distribution I would have to re-build all my cabal packages with
> -static?  And if I change my default so that cabal builds with
> -static GHCI would no longer work for me?

You can configure Cabal to build both static and dynamic libraries
whenever you install anything - but it'll take twice as long.

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 be different.

The tricky bit is that it only works if all the dependencies have been
compiled for both ways at the same time too. If any dependencies were
built with different options for static and dynamic, or even if there
was just a different random name generated, then things can go wrong.
So we need to work out the details so that nothing breaks.


Thanks
Ian


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic libraries by default and GHC 7.8

Matthias Kilian
In reply to this post by Ian Lynagh-2
Hi,

On Tue, Nov 27, 2012 at 02:52:48PM +0000, 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 be glad to hear your
> feedback, to help us in making our decisions

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.

That's partially because currently we've even a patch explicitely
disabling shared library support in our ports/packages system (last
time I tried with shared lib support, I got some segfaults in the
midst of the build, and unfortunately I'm still too short of time
to debug/fix it).

Ciao,
        Kili

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic libraries by default and GHC 7.8

Ian Lynagh-2
On Tue, Nov 27, 2012 at 08:38:21PM +0100, Matthias Kilian wrote:

> On Tue, Nov 27, 2012 at 02:52:48PM +0000, 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 be glad to hear your
> > feedback, to help us in making our decisions
>
> 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 might
have removed support for GHCi when it's turned off.

Does ghci work for you currently?

Is this a registerised or unregisterised build?

> That's partially because currently we've even a patch explicitely
> disabling shared library support in our ports/packages system (last
> time I tried with shared lib support, I got some segfaults in the
> midst of the build, and unfortunately I'm still too short of time
> to debug/fix it).

That's a bit bizarre. With shared libraries enabled, there still won't
be any dynamically linked programs actually run.


Thanks
Ian


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic libraries by default and GHC 7.8

Evan Laforge
In reply to this post by Ian Lynagh-2
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 way around that?  For instance, I imagine I could
add an extra build step to bundle the .o files up into a .so and then
somehow get ghci to know to load that.  I guess that's like compiling
all the local modules as a separate package and then adding that to
the package db, so in principle it should be possible.

On the plus side, it seems like this would do wonders for link time,
which is currently about 15s of "machine grinds to a halt" for me.  I
didn't see mention of it on the page, but I assume linking a binary
with lots of giant packages is going to be a lot faster if they can be
loaded on demand at runtime... or is just going to make startup really
slow?

On Tue, Nov 27, 2012 at 6:52 AM, Ian Lynagh <[hidden email]> wrote:

>
> 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 are also some policy
> questions we need to answer about how Cabal will work with a GHC that
> uses dynamic libraries by default. We would like to make these as soon
> as possible, so that GHC 7.6.2 can ship with a Cabal that works
> correctly.
>
> 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 decisions
>
>
> Thanks
> Ian
> --
> Ian Lynagh, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic libraries by default and GHC 7.8

Matthias Kilian
In reply to this post by Ian Lynagh-2
Hi,

On Tue, Nov 27, 2012 at 08:15:59PM +0000, 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 might
> have removed support for GHCi when it's turned off.
>
> Does ghci work for you currently?

Yes, but I'm still at ghc-7,4.2. Not enough time to catch up with
recent ghc development :-(

> Is this a registerised or unregisterised build?

Registerised, working on i386 and amd66 (or x86 and x86_64 in the
non-bsd-world).


> > That's partially because currently we've even a patch explicitely
> > disabling shared library support in our ports/packages system (last
> > time I tried with shared lib support, I got some segfaults in the
> > midst of the build, and unfortunately I'm still too short of time
> > to debug/fix it).
>
> That's a bit bizarre. With shared libraries enabled, there still won't
> be any dynamically linked programs actually run.

No worry. There were a lot of changes in OpenBSD during the last 6
months (including dl.so, pthreads, whatever). Wether there's a bug
in the GHC build system, or in the (heavily patched) OpenBSD port,
or in the binaries we use for bootstrapping, I really dont't know.
I wouldn't ve surprised if it's some breakage on my side (with the
bootstrappers i supply).

Ciao,
        Kili

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic libraries by default and GHC 7.8

Joachim Breitner
In reply to this post by Ian Lynagh-2
Hi,

Am Dienstag, den 27.11.2012, 14:52 +0000 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 decisions

here comes the obligatory butting in by the Debian Haskell Group:

Given the current sensitivity of the ABI hashes we really do not want to
have Programs written in Haskell have a runtime dependency on all the
included Haskell libraries. So I believe we should still link Haskell
programs statically in Debian.

Hence, Debian will continue to provide its libraries built the static
way.

Building them also in the dynamic way for the sake of GHCi users seems
possible.

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 break when the user upgrades its Haskell packages, as the
package management is ignorant of unpackaged, locally built programs.
I’d feel more comfortable if that could not happen.

Other open question: Should we put the dynamic libraries in the normal
libghc-*-dev package? Con: Package size doubles (and xmonad users are
already shocked by the size of stuff they need to install). Pro: It
cannot happen that I can build Foo.hs statically, but not load it in
GHCi, or vice-versa.

I still find it unfortunate that once cannot use the .so for static
linking as well, but that is a problem beyond the scope of GHC.

Greetings,
Joachim

--
Joachim "nomeata" Breitner
Debian Developer
  [hidden email] | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: [hidden email] | http://people.debian.org/~nomeata

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic libraries by default and GHC 7.8

Ian Lynagh-2
In reply to this post by Evan Laforge
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 ghci will have to interpret all local moules?

No, it links them into a temporary .so in /tmp and dlopens that.

> On the plus side, it seems like this would do wonders for link time,
> which is currently about 15s of "machine grinds to a halt" for me.  I
> didn't see mention of it on the page, but I assume linking a binary
> with lots of giant packages is going to be a lot faster if they can be
> loaded on demand at runtime... or is just going to make startup really
> slow?

It looks like it's fractionally slower on x86_64/Linux:

Using static libraries with ghci:
$ time echo GHC.maxPrecedence | ghc --interactive -package ghc -v0
9
1.00s user 0.12s system 100% cpu 1.122 total

Using dynamic libraries with ghci:
$ time echo GHC.maxPrecedence | ghc --interactive -package ghc -v0
9
1.01s user 0.15s system 101% cpu 1.141 total


Thanks
Ian


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic libraries by default and GHC 7.8

Dag Odenhall
In reply to this post by Ian Lynagh-2
On Tue, Nov 27, 2012 at 3:52 PM, Ian Lynagh <[hidden email]> 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 100ms, which is particularly noticeable when used via its bash completions which call the program to provide completions.

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic libraries by default and GHC 7.8

Dag Odenhall
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, [hidden email] <[hidden email]> wrote:
On Tue, Nov 27, 2012 at 3:52 PM, Ian Lynagh <[hidden email]> 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 100ms, which is particularly noticeable when used via its bash completions which call the program to provide completions.


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic libraries by default and GHC 7.8

Dag Odenhall
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, [hidden email] <[hidden email]> wrote:
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, [hidden email] <[hidden email]> wrote:
On Tue, Nov 27, 2012 at 3:52 PM, Ian Lynagh <[hidden email]> 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 100ms, which is particularly noticeable when used via its bash completions which call the program to provide completions.



_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic libraries by default and GHC 7.8

Tyson Whitehead
In reply to this post by Joachim Breitner
On Wed, 2012-11-28 at 00:28 +0100, Joachim Breitner wrote:

> Am Dienstag, den 27.11.2012, 14:52 +0000 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 decisions
>
> here comes the obligatory butting in by the Debian Haskell Group:
>
> Given the current sensitivity of the ABI hashes we really do not want to
> have Programs written in Haskell have a runtime dependency on all the
> included Haskell libraries. So I believe we should still link Haskell
> programs statically in Debian.
>
> Hence, Debian will continue to provide its libraries built the static
> way.

I was so excited for a bit thinking that this would finally mean that
Debian would move to a dynamic system.  Every haskell binary being 10s
of MBs (e.g., pandoc = 25MB executable) makes it look kind of bad.

From our previous discussion on this

http://lists.debian.org/debian-haskell/2010/03/msg00120.html

it seemed a big part of the problem is you really need to be able to
have multiple versions of the same package installed.

At the time, I believe the only way to do this was to include part of
the hash in the name, but that meant you had to constantly be creating
new packages which Debian didn't make easy.

Maybe it is time to explain the problem to the Debian packaging people
and see if they have any ideas from their level?

> Building them also in the dynamic way for the sake of GHCi users seems
> possible.

I was left with the impression that we were going to have this back in
2010 just as soon as squeeze got out the door...  :)

http://lists.debian.org/debian-haskell/2010/03/msg00155.html

Cheers!  -Tyson

PS:  Another solution might to move up one level.  That is, use the
packages in some way other than for actual standard packaging.

For example, they could be taken to mean what the user wants built.  The
installed packages then becomes the roots in a NIX style store.

Another example, do something like akmods system under redhat.  The
package actually builds a new locally generated package that is then
installed to get around the can't easily create new package issue.


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic libraries by default and GHC 7.8

Jens Petersen
In reply to this post by Ian Lynagh-2
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 dynamic linking for Linux.
I think Fedora was probably the first Linux distro to enable ghc
shared libs and use dynamic linking for executables in our packages.
Having ghci and cabal linking benefiting from dynamic linking seems a
positive step forward indeed IMHO.
I hope we will see ghc shared libs support spreading also to other
Linux archs (particularly ARM).

Sure it will change deployment workflow somewhat but that is what
Linux distros are for. :)

I am looking forward to test this with Fedora's Haskell packages very much.

Jens

ps Btw RHEL is also increasingly moving to 64bit.

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic libraries by default and GHC 7.8

Brandon Allbery
In reply to this post by Tyson Whitehead
On Tue, Nov 27, 2012 at 9:57 PM, Tyson Whitehead <[hidden email]> wrote:
it seemed a big part of the problem is you really need to be able to
have multiple versions of the same package installed.

At the time, I believe the only way to do this was to include part of
the hash in the name, but that meant you had to constantly be creating
new packages which Debian didn't make easy.

Maybe it is time to explain the problem to the Debian packaging people
and see if they have any ideas from their level?

Not sure they do, because it's a GHC-specific and very nasty problem at core.

The fundamental issue is that GHC does aggressive cross-module inlining to make performance halfway reasonable -- but this means you end up requiring very precise dependencies, because different builds of the same library even with the same compiler might for some reason expose different things for inlining, and that ends up infecting the whole dependency chain.  Done statically, the result is the infamous Cabal hell; done dynamically, it means shared library hell.  I am not sure it can be made sane in either case.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic libraries by default and GHC 7.8

Ganesh Sittampalam
In reply to this post by Ian Lynagh-2
On 27/11/2012 14:52, 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.
>
> 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 are also some policy
> questions we need to answer about how Cabal will work with a GHC that
> uses dynamic libraries by default. We would like to make these as soon
> as possible, so that GHC 7.6.2 can ship with a Cabal that works
> correctly.
>
> The various issues are described in a wiki page here:
>     http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault

If I understand the problem on Windows correctly, you can use dynamic
libraries for ghci, but using them for compiled executables is difficult
because there's no good solution for having the compiled exe find its DLLs.

If so, does that mean that you intend to switch over ghci to dynamic and
build static+dynamic by default, or are you going to leave ghci as static?

My general feeling about Windows is that it's ok for the end result to
be a little annoying, because Windows DLLs *are* annoying and it's
nothing to do with GHC.

In particular I think in practice most Windows developers will have
admin rights and could live with the ghc installation and cabal install
having to be done as elevated operations. Where they weren't done with
admin rights, then ghc -o could warn the user that the DLLs need to be
copied locally (or even copy them itself and tell the user it happened).

More generally, if you can implement the "half a plan" you mentioned
elsewhere in the thread for quickly building both static and dynamic
ways, then the combination of the ABI and performance issues mean that
I'm marginally in favour of keeping static linking as the default for
executables on all platforms, but building the dynamic libraries for ghci.

Cheers,

Ganesh

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic libraries by default and GHC 7.8

Jens Petersen
In reply to this post by Ian Lynagh-2
On 28 November 2012 03:02, Ian Lynagh <[hidden email]> 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 be different.

Perhaps this plan could be used for a transition phase?
If a simple pass were enough to generate both dyn and static
(which I could then also check off my ghc wishlist:-)
then a compromise might be to make ghc/Cabal default to generating
both until ghc8 is released?
Still defaulting to dynamic linking of executables of course.
By that time people should be sufficiently used to the change.
Such a softer transition plan might be more generally acceptable to
Linux and MacOS users?

To me being able to default ghc and Cabal to use just dyn will be big
improvement.

Could you say more about the impact to ghc-7.6.2 Cabal?

Jens

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic libraries by default and GHC 7.8

Jens Petersen
In reply to this post by Joachim Breitner
On 28 November 2012 08:28, Joachim Breitner <[hidden email]> 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 break when the user upgrades its Haskell packages, as the
> package management is ignorant of unpackaged, locally built programs.
> I’d feel more comfortable if that could not happen.

Right, I tried patching Fedora's xmonad for a while to use dynamic linking
(it made Mod-q almost instant! :-) but finally reverted it not to confuse people
linking their .xmonad/ to user libraries, at least until the time
ghc/Cabal support dyn by default...

Jens

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
1234