Re: Dynamic libraries by default and GHC 7.8
On 27/11/12 23:28, Joachim Breitner wrote: 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 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. So let me try to articulate the options, because I think there are some dependencies that aren't obvious here. It's not a straightforward choice between -dynamic/-static being the default, because of the GHCi interaction. Here are the 3 options: (1) (the current situation) GHCi is statically linked, and -static is the default. Uses the RTS linker. (2) (the proposal, at least for some platforms) GHCi is dynamically linked, and -dynamic is the default. Does not use the RTS linker. (3) GHCi is dynamically linked, but -static is the default. Does not use the RTS linker. Packages must be installed with -dynamic, otherwise they cannot be loaded into GHCi, and only objects compiled with -dynamic can be loaded into GHCi. You seem to be saying that Debian would do (3), but we hadn't considered that as a viable option because of the extra hoops that GHCi users would have to jump through. We consider it a prerequisite that GHCi continues to work without requiring any extra flags. Cheers, Simon 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On 27/11/12 14:52, Ian Lynagh 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 Thanks for doing all the experiments and putting this page together, it certainly helps us to make a more informed decision. 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 My personal opinion is that we should switch to dynamic-by-default on all x86_64 platforms, and OS X x86. The performance penalty for x86/Linux is too high (30%), and there are fewer bugs affecting the linker on that platform than OS X. I am slightly concerned about the GC overhead on x86_64/Linux (8%), but I think the benefits outweigh the penalty there, and I can probably investigate to find out where the overhead is coming from. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
Am Mittwoch, den 28.11.2012, 16:14 +0900 schrieb Jens Petersen: 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 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... but would that not mean that when they upgrade a library used by xmonad, their xmonad binary would stop working and they could not even log in any more? It is that kind of breakage that is worrying me. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
Hi, Am Dienstag, den 27.11.2012, 21:57 -0500 schrieb Tyson Whitehead: 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. its not like dynamic libraries make the bytes disappear – the (non-Haskell-developer) user who wants to use pandoc still has to install all these bytes, but now they just come split in a dozen of packages. Or gix-annex, a more and more popular Haskell application: Building it requires 94 Haskell library packages. Now imagine this to be dynamically built: Now installing git-annex will require 94 strage sounding packages that the user most likely has no idea what they are about, and chances are high that there is no other packages requiring these shared libraries, making most of the benefit of shared libraries moot. Now, if Haskell was as popular as C and the user _would_ run several different processes at once that could share the shared library, this would be interesting. At the moment, I do not see how dynamically built Haskell programs are in the interest of our user. 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... :) It seems that noone cared enough about that, but any help is welcome. Two things to do: Patch haskell-devscripts to build the -dyn ways, and manually adding the additional package stance to the debian/contol files (if it is to be decided that the -dyn libraries should reside in packages of their own. If we decide to include them in the regular packages, this is not needed.) Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
Ian Lynagh i...@well-typed.com writes: [...] There are also some policy questions we need to answer about how Cabal will work with a GHC that uses dynamic libraries by default. btw, how is it planned to have .so libraries interact with the soon-to-be-released cabal-install sandbox feature? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On Wed, Nov 28, 2012 at 12:34:03PM +0100, Herbert Valerio Riedel wrote: Ian Lynagh i...@well-typed.com writes: [...] There are also some policy questions we need to answer about how Cabal will work with a GHC that uses dynamic libraries by default. btw, how is it planned to have .so libraries interact with the soon-to-be-released cabal-install sandbox feature? I don't think anything special needs to be done. The RPATHs will still point to the right DLL if it's in a sandbox. Please let me know if there's a problem that I'm missing, though! Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On Wed, Nov 28, 2012 at 12:28:31AM +0100, Joachim Breitner wrote: 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. Note that you'll have to link ghc dynamically or ghci won't work. This won't cause dependency problems, though, as ghc comes with all the libraries that it needs. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On Wed, Nov 28, 2012 at 09:09:58AM +, Simon Marlow wrote: On 27/11/12 23:28, Joachim Breitner wrote: Hence, Debian will continue to provide its libraries built the static way. So let me try to articulate the options, because I think there are some dependencies that aren't obvious here. It's not a straightforward choice between -dynamic/-static being the default, because of the GHCi interaction. Here are the 3 options: (1) (the current situation) GHCi is statically linked, and -static is the default. Uses the RTS linker. (2) (the proposal, at least for some platforms) GHCi is dynamically linked, and -dynamic is the default. Does not use the RTS linker. (3) GHCi is dynamically linked, but -static is the default. Does not use the RTS linker. Packages must be installed with -dynamic, otherwise they cannot be loaded into GHCi, and only objects compiled with -dynamic can be loaded into GHCi. You seem to be saying that Debian would do (3), but we hadn't considered that as a viable option because of the extra hoops that GHCi users would have to jump through. We consider it a prerequisite that GHCi continues to work without requiring any extra flags. I think what Joachim means is that the binaries /in Debian packages/ will be explicitly linked with -static, but the open question below is about whether to make -static or -dynamic the default for GHC. 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. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On Wed, Nov 28, 2012 at 09:20:57AM +, Simon Marlow wrote: My personal opinion is that we should switch to dynamic-by-default on all x86_64 platforms, and OS X x86. The performance penalty for x86/Linux is too high (30%), FWIW, if they're able to move from x86 static to x86_64 dynamic then there's only a ~15% difference overall: Run Time -1 s.d. - -18.7% +1 s.d. - +60.5% Average - +14.2% Mutator Time -1 s.d. - -29.0% +1 s.d. - +33.7% Average - -2.6% GC Time -1 s.d. - +22.0% +1 s.d. - +116.1% Average - +62.4% I am slightly concerned about the GC overhead on x86_64/Linux (8%), but I think the benefits outweigh the penalty there, and I can probably investigate to find out where the overhead is coming from. Improving this would also help the above, of course. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On Wed, Nov 28, 2012 at 04:00:02PM +0900, Jens Petersen wrote: Could you say more about the impact to ghc-7.6.2 Cabal? For example, question 8 is about whether Cabal should also build static libraries for a dynamic-by-default compiler. We would like to ship a version of Cabal that does the right thing with GHC 7.6.2. That will hopefully mean that by the time GHC 7.8 is released, people will have a Haskell Platform that contains a cabal-install that knows the right way to build things for GHC 7.8. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On Wed, Nov 28, 2012 at 06:43:09AM +, Ganesh Sittampalam wrote: 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. Right. 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? 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). Personally, I would prefer the C stub option to that. 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. That would solve the installing libraries takes twice as long problem, but not the ghci can't load modules compiled with ghc -c problem. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On 28/11/12 12:48, Ian Lynagh wrote: On Wed, Nov 28, 2012 at 09:20:57AM +, Simon Marlow wrote: My personal opinion is that we should switch to dynamic-by-default on all x86_64 platforms, and OS X x86. The performance penalty for x86/Linux is too high (30%), FWIW, if they're able to move from x86 static to x86_64 dynamic then there's only a ~15% difference overall: Run Time -1 s.d. - -18.7% +1 s.d. - +60.5% Average - +14.2% Mutator Time -1 s.d. - -29.0% +1 s.d. - +33.7% Average - -2.6% GC Time -1 s.d. - +22.0% +1 s.d. - +116.1% Average - +62.4% The figures on the wiki are different: x86 static - x86_64 dynamic has +2.3% runtime. What's going on here? I'm not sure I buy the argument that it's ok to penalise x86/Linux users by 30% because they can use x86_64 instead, which is only 15% slower. Unlike OS X, Linux users using the 32-bit binaries probably have a 32-bit Linux installation, which can't run 64-bit binaries (32-bit is still the recommended Ubuntu installation for desktops, FWIW). Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On 28/11/2012 13:13, Ian Lynagh wrote: 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). Personally, I would prefer the C stub option to that. I think that one would be ok too, but I somewhat prefer SxS simply because of the long-term costs of being non-standard. 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. That would solve the installing libraries takes twice as long problem, but not the ghci can't load modules compiled with ghc -c problem. Can't ghc -c also produce both static and dynamic objects? I guess only one of the two could be called sourcefile.o Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On Wed, Nov 28, 2012 at 01:28:54PM +, Simon Marlow wrote: On 28/11/12 12:48, Ian Lynagh wrote: On Wed, Nov 28, 2012 at 09:20:57AM +, Simon Marlow wrote: My personal opinion is that we should switch to dynamic-by-default on all x86_64 platforms, and OS X x86. I should have deleted the above sentence. The performance penalty for x86/Linux is too high (30%), FWIW, if they're able to move from x86 static to x86_64 dynamic then there's only a ~15% difference overall: Run Time -1 s.d. - -18.7% +1 s.d. - +60.5% Average - +14.2% Mutator Time -1 s.d. - -29.0% +1 s.d. - +33.7% Average - -2.6% GC Time -1 s.d. - +22.0% +1 s.d. - +116.1% Average - +62.4% The figures on the wiki are different: x86 static - x86_64 dynamic has +2.3% runtime. What's going on here? +2.3% on OS X, +14.2% on Linux. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
Somebody signing messages as Joachim Breitner wrote: 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. This is also a concern I have. Hence, Debian will continue to provide its libraries built the static way. Right. Building them also in the dynamic way for the sake of GHCi users seems possible. Perhaps Debian could just ship a GHCi that uses the RTS linker, as now? The change is to be made for some platforms, we could opt to have Debian not be such a platform. -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On Wed, Nov 28, 2012 at 01:34:22PM +, Ganesh Sittampalam wrote: On 28/11/2012 13:13, Ian Lynagh wrote: 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. That would solve the installing libraries takes twice as long problem, but not the ghci can't load modules compiled with ghc -c problem. Can't ghc -c also produce both static and dynamic objects? That's true, it could. Simon will point out that build systems will need updating if we start generating more/different files, but perhaps the pain would be worthwhile. I've been thinking about how to actually implement the half-plan. How about this? (don't worry about the names I've used for things for now): * Add a new way, dynstatic. Compiling Foo this way makes Foo.ds_hi Foo.ds_s_o -- static Foo.ds_d_o -- dynamic and by default links statically. There's a flag to make it link dynamically instead. * When compiling things the dynstatic way, all dependencies must be compiled the dynstatic way * When compiling things the static way, dependencies can be compiled either the static or the dynstatic way * When compiling things the dynamic way, dependencies can be compiled either the dynamic or the dynstatic way * Cabal compiles dynstatic by default * ghc compiles dynstatic (linking statically) by default * ghci uses dynamic libraries on all platforms * If we are worried about performance of the compiler, then ship ghc as a static binary and ghci as a separate dynamic binary. The size of the two combined is only 2-3% larger than just the static binary. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On November 28, 2012 04:45:57 Joachim Breitner wrote: Am Dienstag, den 27.11.2012, 21:57 -0500 schrieb Tyson Whitehead: 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. its not like dynamic libraries make the bytes disappear – the (non-Haskell-developer) user who wants to use pandoc still has to install all these bytes, but now they just come split in a dozen of packages. My point was more trying to get at the idea that maybe we don't need a separate copy of most of the bytes in each application. Or gix-annex, a more and more popular Haskell application: Building it requires 94 Haskell library packages. Now imagine this to be dynamically built: Now installing git-annex will require 94 strage sounding packages that the user most likely has no idea what they are about, and chances are high that there is no other packages requiring these shared libraries, making most of the benefit of shared libraries moot. Now, if Haskell was as popular as C and the user _would_ run several different processes at once that could share the shared library, this would be interesting. At the moment, I do not see how dynamically built Haskell programs are in the interest of our user. I guess this is really a question of how many haskell programs are there being used out there. From the looks of popcon results, there isn't a whole lot of take up on anything at moment apart from ghc, xmond, and pandoc. 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... :) It seems that noone cared enough about that, but any help is welcome. Two things to do: Patch haskell-devscripts to build the -dyn ways, and manually adding the additional package stance to the debian/contol files (if it is to be decided that the -dyn libraries should reside in packages of their own. If we decide to include them in the regular packages, this is not needed.) Fair enough. If I was update my 2010 patch so it worked again at some point in the upcoming year (I don't have the time to do this at the moment), would there be a reasonable chance it would seem worthwhile to include it at this point? Please feel free to say no here if that is the case. I realize that maybe in a few years, when there are even more haskell applications, we can revisit the again, and possibly then it will make more sense. Cheers! -Tyson PS: I don't mean to be critical here. You've done a lot of work supporting haskell under Debian, and it's all volunteer. I really appreciate that. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On November 27, 2012 22:02:33 Jens Petersen 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. 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). Hi Jens, I was curious how Fedora has managed to go dynamic given the various issues that the Debian team has brought up. Is the situation on Fedora somehow different? Is there something clever you are doing that gets around this issues? Thanks! -Tyson ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On Wed, Nov 28, 2012 at 11:04:44AM -0500, Stephen Paul Weber wrote: Building them also in the dynamic way for the sake of GHCi users seems possible. Perhaps Debian could just ship a GHCi that uses the RTS linker, as now? The change is to be made for some platforms, we could opt to have Debian not be such a platform. This isn't a good long-term plan. Even if we don't actively remove support for other platforms (which we plan to do), they'll probably bitrot, and the current bugs won't be fixed. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
Hi, Am Mittwoch, den 28.11.2012, 11:35 -0500 schrieb Tyson Whitehead: 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... :) It seems that noone cared enough about that, but any help is welcome. Two things to do: Patch haskell-devscripts to build the -dyn ways, and manually adding the additional package stance to the debian/contol files (if it is to be decided that the -dyn libraries should reside in packages of their own. If we decide to include them in the regular packages, this is not needed.) Fair enough. If I was update my 2010 patch so it worked again at some point in the upcoming year (I don't have the time to do this at the moment), would there be a reasonable chance it would seem worthwhile to include it at this point? Please feel free to say no here if that is the case. I realize that maybe in a few years, when there are even more haskell applications, we can revisit the again, and possibly then it will make more sense. there was even a patch? Sorry then, this is not how contributors should be treated. Given that dynamic linking is becoming the default elsewhere, we should definitely provide it with the next release. So yes, please do look again at the issue. We currently have one package providing dynamic libraries, and that is ghc-dyn. It contains lots of .dyn_hi and some .so files. Which of these are required at runtime? What is the space ratio between the .dyn_hi (which presumably are only required at build time) and the .so files? Do we want separate packages that contain only the files required at runtime? What should be the filename (just libghc-foo?)? Where do the .dyn_hi files go? If a user only build dynamically (only staticaly, both), what packages does she needs? Make liberal use of package-version-hash-base virtual package names (e.g. one set of names for the build time requirements with dynamic packages and one set of names for whats required at runtime) to ensure that we can revise these decisions without breaking everything. But this is getting too specific for glasgow-haskell-users, I guess. replies on this issue please only to d-haskell. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
Ian Lynagh i...@well-typed.com writes: On Wed, Nov 28, 2012 at 12:34:03PM +0100, Herbert Valerio Riedel wrote: Ian Lynagh i...@well-typed.com writes: [...] There are also some policy questions we need to answer about how Cabal will work with a GHC that uses dynamic libraries by default. btw, how is it planned to have .so libraries interact with the soon-to-be-released cabal-install sandbox feature? I don't think anything special needs to be done. The RPATHs will still point to the right DLL if it's in a sandbox. Please let me know if there's a problem that I'm missing, though! I'm not sure yet if there's a problem, but doesn't using RPATH cause the cabal sandbox path getting hardcoded into the compiled binaries? I'm just wondering if such a sandboxed build would be deployable/redistributable then. For instance, IIRC, autotools/libtools based packages use wrapper-scripts to point the dynamic linker to the build-local (i.e. not installed yet) shared objects via env-vars and (used to) set the RPATH to the target install path where the shared objects will be found if the package is actually installed. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
What does gcc do? Does it link statically or dynamically by default? Does it depend on if it can find a dynamic version of libraries or not? -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
