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
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:
- 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.
- 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+.
Jens,
On 03/10/2013 12:33 AM, Jens Petersen wrote:
- build and install ghc-rpm-macros
- build and install ghc with bootstrapping set in ghc.spec
- build and install bootstrap (static) hscolour (I should probably just give up and make it statically linked)
- rebuild ghc (with bootstrapping unset) and install it
- 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?
- 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
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@elehack.netwrote:
Jens,
On 03/10/2013 12:33 AM, Jens Petersen wrote:
- build and install ghc-rpm-macros
- build and install ghc with bootstrapping set in ghc.spec
- build and install bootstrap (static) hscolour (I should probably just
give up and make it statically linked)
- rebuild ghc (with bootstrapping unset) and install it
- 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?
- 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/haskell
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
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
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/haskell
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
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
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.
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
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
On 03/10/2013 12:33 AM, Jens Petersen wrote:
- build and install ghc-rpm-macros
- build and install ghc with bootstrapping set in ghc.spec
- 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
haskell@lists.fedoraproject.org
-
Garrett Mitchener -
Jens-Ulrik Petersen -
Michael Ekstrand