haskell March 2014

haskell@lists.fedoraproject.org

3 participants
6 discussions

Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
by Jens-Ulrik Petersen 29 Mar '14

29 Mar '14

Hi Adam, > > > We'd like to update to Mesa 10.1 in Fedora 20, since the cycle is so > > > long before F21 and (among other goodies) it enables OpenGL 3.3 on some > > > newer Radeons. This implies rebasing LLVM 3.4, and that's where it gets > > > a little awkward: the OpenGTL package only works up to LLVM 3.3. > > > > One concern from me is that ghc on ARM uses llvm as its compiler backend. > > Thanks for letting me know! ghc doesn't show up as an llvm-libs > consumer on amd64 so I hadn't caught this. Right - I think even on ARM only llvm would show up. > Is it possible to build the llvm backend on other arches, even if only > locally? That might at least allow me to shake out issues with the llvm > code outside of actual codegen. It is built by default at least on intel archs - just not used by default. GHC ARM is kind of an anomaly using llvm by default - intel archs and ppc 32bit have (good) native code generators and so don't use the newer llvm backend in their compilation pipeline. You can test ghc with llvm on intel archs with the -fllvm. What you probably want to do is to change or patch ghc-rpm-macros locally to pass the -fllvm flag to ghc via Haskell Cabal buildsystem. I can send you a diff for that. Or you can tweak individual Haskell packages to use llvm by adding: %define cabal_configure_options --ghc-option=-fllvm at the beginning of their %build sections. (A more expensive way would be to rebuild all the current packages in Rawhide which would cause them to be rebuild with llvm-3.4 on ARM, but that is probably overkill and I hope we can move Rawhide ghc to 7.8 soon anyway) Thanks, Jens

1 0

Re: RC2 release imminent
by Jens Petersen 14 Mar '14

14 Mar '14

On 2 March 2014 22:23, Jens Petersen <juhpetersen(a)gmail.com> wrote: > New source distributions are available here: >> http://www.haskell.org/ghc/dist/7.8.1-rc2/ > > : > I have done a couple of testbuilds: > http://koji.fedoraproject.org/koji/taskinfo?taskID=6586630 (built against > ghc-7.6.3) > and a build in my Fedora Copr ghc-7.8 repo for Fedora 20 > http://copr.fedoraproject.org/coprs/petersen/ghc-7.8/ (against the > original RC2) > I did a test build on Fedora Rawhide s390/s390x too: http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1364690 A test build on ppc completed but then the dyn executable sanity check failed (not yet sure why): http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=1707922

1 0

Haskell executables dynamic vs static linking
by Jens-Ulrik Petersen 12 Mar '14

12 Mar '14

For a long time I was quite "proud" that Fedora Haskell is using dynamic Haskell linking on primary intel architectures (ghc-7.8 should support shared libs also on ARM, but it and cabal 1.18 still default to static linking.) But of course there are pros and cons for dynamic linking against Haskell libraries. pros: - smaller lighter executables - enforces rebuilding of reverse deps (though this can also be a cons) - makes use of shared libs to share Haskell object code in memory - faster linking cons: - harder to deploy - less portable - dynamically linked tools makes testing/building (for) newer ghc harder Today I decided to make hscolour statically linked against Haskell libs in Rawhide. This will make bootstrapping ghc-7.8.1 or snapshots easier for example, or building ghc rpms for any other version. [1] I think this is less problematic anyway for BinLib packages like hscolour, since ghc-hscolour will pick up any potential dependency breakage anyway. I would like to have a static executable for cabal-install too. Maybe a cleaner alternative is to provide both a dynamic and a static subpackage, but I am not sure yet on the best way to do that. Using alternatives might be the only realistic way currently perhaps? Should we do that for more executables packages? Currently in Fedora because cabal-install is dynamically linked it is some work to build cabal-install for a new ghc version which makes testing newer ghc harder. If we had a statically linked cabal-install package we could just use it with any (recent) version of ghc... ie it would be more portable. Any thoughts or opinions on this? AFAIK Fedora is the only big distro that packages executables dynamically linked to Haskell libraries. Jens [1] Actually I wish hscolour was just included in ghc. It would make life easier. And likewise cabal-install actually.

3 6

Re: Cabal-1.18.1.3 and cabal-install-1.18.0.3 releases made
by Jens Petersen 06 Mar '14

06 Mar '14

On 5 March 2014 06:28, Johan Tibell <johan.tibell(a)gmail.com> wrote: > I've just made a release of Cabal/cabal-install, for the benefit of GHC > 7.8. > Thanks!! I have now built them for Fedora 19 and 20 in my Fedora Copr repos: https://copr.fedoraproject.org/coprs/petersen/cabal-install/ https://copr.fedoraproject.org/coprs/petersen/Cabal (static only) You can also browse the repo at < http://copr-be.cloud.fedoraproject.org/results/petersen/cabal-install/> for example. Some notes: since the ghc-Cabal-devel package conflicts with the one in the Fedora repos I built it in a separate copr repo and then built cabal-install separately on top of that in its own repo so cabal-install can be updated without having to touch the system Cabal library (since other Fedora packages are linked to it), but I think some of the newer cabal-install features will not work unless one installs Cabal-1.18. Let me know if you have any problems or feedback on the packages/repos. Jens

1 0

mbuf's packages
by Jens-Ulrik Petersen 04 Mar '14

04 Mar '14

Hi, I got a message from Shakthi Kannan that he has changed job and doesn't really have time now for maintaining Fedora Haskell packages, and he has already orphaned his packages!: ghc-ForSyDe (*) ghc-HSH (*) ghc-IOSpec ghc-MonadCatchIO-mtl (*) ghc-MonadRandom ghc-Stream ghc-ansi-terminal (*) ghc-arrows ghc-blaze-textual ghc-data-inttrie ghc-data-memocombinators ghc-data-reify ghc-dotgen ghc-lambdabot-utils ghc-lazysmallcheck ghc-logict ghc-netlist ghc-netlist-to-vhdl ghc-numbers ghc-oeis ghc-parameterized-data (*) ghc-readline ghc-show ghc-sized-types ghc-smallcheck (*) ghc-type-level (*) unlambda Most of them are for Fedora only and if you are interested in owning any of them you can grab them in Fedora Pkgdb. I will probably take the remaining ones next week, but if there are any that particularly interest you or that you would like to comaintain do let us know! Many of them are related to his interest in Electronics and also his packaging of lambdabot: anyone interested in having lambdabot in Fedora? Jens (*) I grabbed these earlier but then thought I should ask here if others are interested in any of these packages before taking any more.

1 1

ghc-7.8 RC2'
by Jens-Ulrik Petersen 03 Mar '14

03 Mar '14

Hi, Latest ghc-7.8.1 RC2 is now in my copr repo: https://copr.fedoraproject.org/coprs/petersen/ghc-7.8/ It seems to work okay for me. (Bootstrapping cabal-install is slightly tedious until new cabal-install is released.) Jens

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

haskell March 2014