rebuilding newer haskell for EL6

[Michael Ekstrand]

I'm trying to rebuild part of F18's Haskell stack for EL6, so I can have
newer packages than what EPEL currently offers, and am not quite sure
how to do the initial bootstrap. I got stuff built, but had problems
with it, and am concerned I may not have bootstrapped it correctly.

The three packages 'ghc-rpm-macros', 'ghc', and 'hscolour' seem to
be
intricately interlinked, requiring bootstrap builds and then
non-bootstrap rebuilds in order to work.

So, could someone enlighten me on two things:

1. What is the procedure for bootstrapping a new Haskell version?  Which
packages do I need to bootstrap, in what order?  Do I need to bump
revision numbers between bootstrap and rebuild, or can I rebuild the
full version with the same revision?

2. Is anything else needed? Or am I good to go rebuilding additional
Haskell packages in dependency order once I've bootstrapped
ghc-rpm-macros, ghc, and hscolour?

TIA,
- Michael

[Jens-Ulrik Petersen]

Hi Michael,

>  I'm trying to rebuild part of F18's Haskell stack for EL6, so
> I can
>  have newer packages than what EPEL currently offers, and am not quite sure
>  how to do the initial bootstrap. I got stuff built, but had problems
>  with it, and am concerned I may not have bootstrapped it correctly.
>  
>  The three packages 'ghc-rpm-macros', 'ghc', and 'hscolour' seem
> to be
>  intricately interlinked, requiring bootstrap builds and then
>  non-bootstrap rebuilds in order to work.
>  
>  So, could someone enlighten me on two things:
>  
>  1. What is the procedure for bootstrapping a new Haskell version?
>   Which packages do I need to bootstrap, in what order?  Do I need to bump
>  revision numbers between bootstrap and rebuild, or can I rebuild the
>  full version with the same revision? 
1. build and install ghc-rpm-macros
2. build and install ghc with bootstrapping set in ghc.spec
3. build and install bootstrap (static) hscolour (I should probably just give up and make
it statically linked)
4. rebuild ghc (with bootstrapping unset) and install it
5. rebuild dynamic hscolour (can also be done later as needed)

Then you should be fine.  I hope I didn't miss anything.

>  2. Is anything else needed? Or am I good to go rebuilding additional
>  Haskell packages in dependency order once I've bootstrapped
>  ghc-rpm-macros, ghc, and hscolour? 
You should be yes: but if not, if you can tell what went wrong
I can try to be of more help.

Jens

ps I probably won't update EPEL 6 ghc to 7.4 until after Fedora has been released with
7.6+;
   I expect EPEL 7 will ship with ghc 7.6+.

[Michael Ekstrand]

Jens,

On 03/10/2013 12:33 AM, Jens Petersen wrote:
>  1. build and install ghc-rpm-macros
>  2. build and install ghc with bootstrapping set in ghc.spec
>  3. build and install bootstrap (static) hscolour (I should probably just give up and make
> it statically linked)
>  4. rebuild ghc (with bootstrapping unset) and install it
>  5. rebuild dynamic hscolour (can also be done later as needed)
>  
>  Then you should be fine.  I hope I didn't miss anything. 
Thanks! If I need to build ghc-rpm-macros twice (it doesn't seem to
build non-bootstrapped before the new ghc is built), where in the
process does the non-bootstrap build come? Or does it matter much?

> > 2. Is anything else needed? Or am I good to go rebuilding
> additional
> > Haskell packages in dependency order once I've bootstrapped
> > ghc-rpm-macros, ghc, and hscolour?
>  
>  You should be yes: but if not, if you can tell what went wrong
>  I can try to be of more help. 
The symptom I was seeing was segfaults, specifically in HsSyck.  Given
that I wasn't confident in my build, and had seen some anomalies while
working on it, I want to make sure that I have the stack properly built,
then try to chase down whatever might be wrong on the HsSyck side.

- Michael

[Garrett Mitchener]

We may be in the same boat and not realize it:  I'm trying to track down a
segfault that appeared when I compiled & ran a previously working
Haskell+GTK program under Fedora 18.  I think there's a bug in how GHC
makes foreign import ccall "wrapper" functions. It appears to be in
versions 7.4 and later.  Something is getting off by 8 bytes, and the
result is a segfault when the wrapper is called.  I see that HsSyck has a
bunch of these in Data/Yaml/Syck.hsc, so maybe we're seeing the same
problem....?

Here's my bug report:

http://hackage.haskell.org/trac/ghc/ticket/7629



On Sun, Mar 10, 2013 at 10:28 AM, Michael Ekstrand <michael(a)elehack.net&gt;wrote:

>  Jens,
>
>  On 03/10/2013 12:33 AM, Jens Petersen wrote:
>  > 1. build and install ghc-rpm-macros
>  > 2. build and install ghc with bootstrapping set in ghc.spec
>  > 3. build and install bootstrap (static) hscolour (I should probably just
>  give up and make it statically linked)
>  > 4. rebuild ghc (with bootstrapping unset) and install it
>  > 5. rebuild dynamic hscolour (can also be done later as needed)
>  >
>  > Then you should be fine.  I hope I didn't miss anything.
>
>  Thanks! If I need to build ghc-rpm-macros twice (it doesn't seem to
>  build non-bootstrapped before the new ghc is built), where in the
>  process does the non-bootstrap build come? Or does it matter much?
>
>  >> 2. Is anything else needed? Or am I good to go rebuilding additional
>  >> Haskell packages in dependency order once I've bootstrapped
>  >> ghc-rpm-macros, ghc, and hscolour?
>  >
>  > You should be yes: but if not, if you can tell what went wrong
>  > I can try to be of more help.
>
>  The symptom I was seeing was segfaults, specifically in HsSyck.  Given
>  that I wasn't confident in my build, and had seen some anomalies while
>  working on it, I want to make sure that I have the stack properly built,
>  then try to chase down whatever might be wrong on the HsSyck side.
>
>  - Michael
>
>  _______________________________________________
>  haskell mailing list
>  haskell(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/haskell
>

[Michael Ekstrand]

On 03/11/2013 09:40 AM, Garrett Mitchener wrote:
>  We may be in the same boat and not realize it:  I'm trying to
> track down
>  a segfault that appeared when I compiled & ran a previously working
>  Haskell+GTK program under Fedora 18.  I think there's a bug in how GHC
>  makes foreign import ccall "wrapper" functions. It appears to be in
>  versions 7.4 and later.  Something is getting off by 8 bytes, and the
>  result is a segfault when the wrapper is called.  I see that HsSyck has
>  a bunch of these in Data/Yaml/Syck.hsc, so maybe we're seeing the same
>  problem....? 
Not sure. I just installed HsSyck from cabal on F18, built and ran my
code no problem.

- Michael

[Michael Ekstrand]

On 03/11/2013 12:22 PM, Michael Ekstrand wrote:
>  On 03/11/2013 09:40 AM, Garrett Mitchener wrote:
> > We may be in the same boat and not realize it:  I'm trying to track down
> > a segfault that appeared when I compiled & ran a previously working
> > Haskell+GTK program under Fedora 18.  I think there's a bug in how GHC
> > makes foreign import ccall "wrapper" functions. It appears to be in
> > versions 7.4 and later.  Something is getting off by 8 bytes, and the
> > result is a segfault when the wrapper is called.  I see that HsSyck has
> > a bunch of these in Data/Yaml/Syck.hsc, so maybe we're seeing the same
> > problem....?
>  
>  Not sure. I just installed HsSyck from cabal on F18, built and ran my
>  code no problem. 
I've finished my rebuild for EL6, and still get the HsSyck segfault. But
no such segfault on F18.

I also rebuilt libffi from F18 for EL6 (well, specifically Scientific
Linux + EPEL), and still segfaults (though I haven't rebuilt the Haskell
stack on top of updated libffi).

- Michael

[Michael Ekstrand]

Further interestingness: this problem seems to be a 32/64-bit issue. My
laptop is 64-bit F18, works fine.  Server is 32-bit SL6, segfault.  I
installed the Haskell stack & dependencies in a 32-bit F18 chroot, and
it also crashes.

I do not know if this is the same bug, but it does seem related.  I
don't have a minimal working reproduction, though.

- Michael

On 03/11/2013 04:57 PM, Michael Ekstrand wrote:
>  On 03/11/2013 12:22 PM, Michael Ekstrand wrote:
> > On 03/11/2013 09:40 AM, Garrett Mitchener wrote:
> >> We may be in the same boat and not realize it:  I'm trying to track down
> >> a segfault that appeared when I compiled & ran a previously working
> >> Haskell+GTK program under Fedora 18.  I think there's a bug in how GHC
> >> makes foreign import ccall "wrapper" functions. It appears to be in
> >> versions 7.4 and later.  Something is getting off by 8 bytes, and the
> >> result is a segfault when the wrapper is called.  I see that HsSyck has
> >> a bunch of these in Data/Yaml/Syck.hsc, so maybe we're seeing the same
> >> problem....?
> >
> > Not sure. I just installed HsSyck from cabal on F18, built and ran my
> > code no problem.
>  
>  I've finished my rebuild for EL6, and still get the HsSyck segfault. But
>  no such segfault on F18.
>  
>  I also rebuilt libffi from F18 for EL6 (well, specifically Scientific
>  Linux + EPEL), and still segfaults (though I haven't rebuilt the Haskell
>  stack on top of updated libffi).
>  
>  - Michael
>  
>  _______________________________________________
>  haskell mailing list
>  haskell(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/haskell
>

[Jens-Ulrik Petersen]

>  Further interestingness: this problem seems to be a 32/64-bit issue.
>  My laptop is 64-bit F18, works fine.  Server is 32-bit SL6, segfault.  I
>  installed the Haskell stack & dependencies in a 32-bit F18 chroot,
>  and it also crashes. 
I see.  The earlier report (https://bugzilla.redhat.com/show_bug.cgi?id=907515)
is also for i686.  So indeed it does seem quite likely to be related.

It might be worth testing upstream's ghc tarballs to make sure it is not
a Fedora specific issue.

>  >> Not sure. I just installed HsSyck from cabal on F18, built
> and ran
>  >> my code no problem. 
This is not for yhc?

Jens

[Michael Ekstrand]

On 03/17/2013 11:37 PM, Jens Petersen wrote:
> > Further interestingness: this problem seems to be a 32/64-bit
> issue.
> > My laptop is 64-bit F18, works fine.  Server is 32-bit SL6, segfault.  I
> > installed the Haskell stack & dependencies in a 32-bit F18 chroot,
> > and it also crashes.
>  
>  I see.  The earlier report (https://bugzilla.redhat.com/show_bug.cgi?id=907515)
>  is also for i686.  So indeed it does seem quite likely to be related.
>  
>  It might be worth testing upstream's ghc tarballs to make sure it is not
>  a Fedora specific issue. 
I'll try that; don't know if I'll get to it before the weekend. I also
tried Rawhide i386 earlier this week, and the problem persists there.

I also hope to come up with a minimal reproducing example, preferably
depending just on HsSyck and not all of Hakyll, to put in the upstream
bug report and perhaps a Fedora-specific one. And see if it's fixed by
GHC 7.6.

> >>> Not sure. I just installed HsSyck from cabal on F18,
> built and ran
> >>> my code no problem.
>  
>  This is not for yhc? 
yhc? I am a bit confused.

At this point, this project is mainly to get my Hakyll site working
consistently on my F18 laptop and SL6 server.  With as many dependencies
managed by RPM as possible.

- Michael

[Jens-Ulrik Petersen]

>  > It might be worth testing upstream's ghc tarballs to make
> sure it
>  > is not a Fedora specific issue.
>  
>  I'll try that; don't know if I'll get to it before the weekend. 
Ok you might need some dummy symlinks for libgmp, etc.

>  I also hope to come up with a minimal reproducing example,
> preferably
>  depending just on HsSyck and not all of Hakyll 
Ok my glib example is pretty small but agreed an isolated example without
any library use would be better.

>  At this point, this project is mainly to get my Hakyll site working
>  consistently on my F18 laptop and SL6 server. 
Ok - how does your Hakyll use HsSyck?

Otherwise might be worth switching to x86_64 as a workaround
but that might also be more work of course...

Jens

ps I think I meant jhc another compiler but anyway.

[Michael Ekstrand]

On 03/21/2013 09:52 PM, Jens Petersen wrote:
> > At this point, this project is mainly to get my Hakyll site
> working
> > consistently on my F18 laptop and SL6 server.
>  
>  Ok - how does your Hakyll use HsSyck? 
Just to load some directory layout information and descriptions from a
YAML file, used to populate an index page.

>  Otherwise might be worth switching to x86_64 as a workaround
>  but that might also be more work of course... 
I've been hoping to avoid that, it's a VM with only 512MB of memory.

- Michael

[Michael Ekstrand]

On 03/21/2013 09:52 PM, Jens Petersen wrote:
> >> It might be worth testing upstream's ghc tarballs to make
> sure it
> >> is not a Fedora specific issue.
> >
> > I'll try that; don't know if I'll get to it before the weekend.
>  
>  Ok you might need some dummy symlinks for libgmp, etc.
>  
> > I also hope to come up with a minimal reproducing example, preferably
> > depending just on HsSyck and not all of Hakyll
>  
>  Ok my glib example is pretty small but agreed an isolated example without
>  any library use would be better. 
Should have looked more closely at size, that is pretty minimal. I just
saw 'glib' and thought 'big'.

Anyway, I can reproduce with HsSyck on upstream's 7.4.2 i386 binaries,
with the following minimal program:

import Data.Yaml.Syck

main = do
  yaml <- parseYaml "test.yaml"
  print yaml

And a little YAML file:
hamster:
  foo: bar

- Michael

[Jens-Ulrik Petersen]

>  On 03/10/2013 12:33 AM, Jens Petersen wrote:
>  > 1. build and install ghc-rpm-macros
>  > 2. build and install ghc with bootstrapping set in ghc.spec
>  > 3. build and install bootstrap (static) hscolour (I should probably
>  > just give up and make it statically linked)
>  > 4. rebuild ghc (with bootstrapping unset) and install it
>  > 5. rebuild dynamic hscolour (can also be done later as needed)
>  > 
>  > Then you should be fine.  I hope I didn't miss anything.
>  
>  Thanks! If I need to build ghc-rpm-macros twice (it doesn't seem to
>  build non-bootstrapped before the new ghc is built), where in the
>  process does the non-bootstrap build come? Or does it matter much? 
Okay sorry I think you right and I forgot that detail:

0. build and install bootstrap ghc-rpm-macros (ie with without_hscolour defined)

(that is newer)

>  The symptom I was seeing was segfaults, specifically in HsSyck.
>  Given that I wasn't confident in my build, and had seen some anomalies
>  while working on it, I want to make sure that I have the stack properly
>  built, then try to chase down whatever might be wrong on the HsSyck side. 
I doubt bootstrapping issues would lead to such a segfault.
It might be the same issue that Garrett mentioned.

Jens