Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
by Jens-Ulrik Petersen
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
9 years, 8 months
Haskell executables dynamic vs static linking
by Jens-Ulrik Petersen
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.
9 years, 8 months
mbuf's packages
by Jens-Ulrik Petersen
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.
9 years, 9 months
