It would be great if somebody could create e current ebuild for ghc-bin of version 6.4 . I am working at ebuilds for Pugs (see portage). It requires ghc 6.4 . Thanks
ghc 6.4 is hard masked at the moment for various reasons. We're not likely to add a ghc-bin version until ghc-6.4 in general is unmasked. From my brief test, the version of pugs in portage at the moment works fine with ghc-6.4 If you're just testing things, you can build ghc-6.4 yourself. You don't need the -bin version (though it does take a couple hours to build ghc) BTW the DEPEND ||( >=dev-lang/ghc-bin-6.2.1 >=dev-lang/ghc-6.2.1 ) should probably be: >=virtual/ghc-6.2.1 See the dev-lang/ghc ebuild or any of the dev-haskell ebuilds.
Oh, and you might want to build pugs using optimisations. It can make quite a runtime speed difference though it makes compilation much slower. Pass the '-O' flag to ghc.
I can imagine that there are various issues. The pugs version in portage is not depending on 6.4 but the current one (6.0.14) is. I know that I can build it with ghc-bin but in order to avoide all this I would like to use ghc-bin. The DEPEND you mentioned was changed by mcummings. He wanted to make pugs available to ghc and ghc-bin users. I will have a look if the Makefile does not include -O anyways. Thank's for the tip though.
The point about virtual/ghc is that both ghc and ghc-bin PROVIDE virtual/ghc. So it's better to depend on virtual/ghc.
Now I got it and fixed it too.
ghc-bin-6.4 will be provided very soon. However, ghc-bin isn't strictly necessary as ghc-6.4 will do for pugs and can be compiled using ghc-bin-6.2.2 ... It's good to see pugs in portage. Cheers, ks
So what happened ? What means very soon ? I don`t expect a date or something but I thought you guys were working on it ... I the ghc(-source) working now ? Thanks ...
Sorry for the delay. Currently, the Haskell team members are all quite busy in their RL's. I have just committed a first version of ghc-bin-6.4, including a binary for x86. We will try to test and add more arches during the next days. Both ghc-bin-6.4 and ghc-6.4 remain package.masked for the moment, because many ghc-based Haskell libraries are still not compatible with the new version. We currently hope to get ghc-6.4 out of package.mask within the next two weeks, but no promises ... Cheers, ks
That`s great ! Within the next two weeks sounds very good. Thanks.
ghc does not appear to be in package.mask anymore. I'm going to go set up a bug for the new pugs version.
(In reply to comment #1) > ghc 6.4 is hard masked at the moment for various reasons. We're not likely to add a ghc-bin version until ghc-6.4 in general is unmasked. > > From my brief test, the version of pugs in portage at the moment works fine with ghc-6.4 > > If you're just testing things, you can build ghc-6.4 yourself. You don't need the -bin version (though it does take a couple hours to build ghc) > > BTW the DEPEND > ||( >=dev-lang/ghc-bin-6.2.1 >=dev-lang/ghc-6.2.1 ) > > should probably be: > >=virtual/ghc-6.2.1 > > See the dev-lang/ghc ebuild or any of the dev-haskell ebuilds. "virtuals being versioned is a common misconception." -- kloeri you'll see, if you try it, that it'll fail trying to build a ~keyword blocked ghc-bin without ever trying to get to ghc. whereas if you use the former, it'll build, for example, ghc-6.4 via ghc-bin-6.2 maybe it'll work someday, though it'd lead to a lot of abiguity as to resolution.
Sorry, but if something is established practice which results from lots of past discussions, in this case with carpaski and jstubbs, you cannot call it a "misconception" that easily. I know that there are some problems related to the "virtual/ghc" solution -- but I cannot follow the negative example you gave, there seems to be something not quite right about it. Bootstrapping ghc via a virtual predates the presence of || in portage, afaik. I think that the main problem with versioned virtuals that kloeri might refer to in the statement cited, is that versioned virtuals completely break down if the version schemes of the different packages that provide the virtual differ. This, however, isn't the case for ghc and ghc-bin. Furthermore, the || (...) dependency solution might have problems on its own: first, it's decentralized and more difficult to maintain; second, it's inconsistent with all the other ghc ebuilds, which makes it a much less tested procedure which might cause difficulties that I cannot see yet. I'm very much in favour of jstubb's GLEP to replace virtuals completely by meta-packages, and I might be willing to convert ghc and ghc-bin to this scheme if it finds his approval, but it's perhaps better to wait until this is accepted in general, and it's definitely better to do it for all ghc-related packages at once rather than adopting inconsistent styles across different ebuilds. Cheers, ks
Nope, versioned virtuals is actually wrong. Portage basically treats virtuals as string - not versioned atoms. Repoman in 2.0.51.22 even complains about versioned virtuals. On the other hand, I have to agree that || ( ) is not a very nice solution due to the decentralised issue but at least it's legal and not depending on 'unofficial' portage behaviour. I can't think of a better solution than || ( ) at the moment - maybe ask the portage guys if there's a better solution?
Your statement is in contradiction to prior statements that I got from carpaski. It is not my place to decide which one of you is wrong. The most likely explanation is that the portage team decided to deprecate this unliked and not-very-well-documented feature. But it's not like I haven't asked the portage guys multiple times about this issue, and they've not had a better solution back then. I will think about moving to || (...), but I'm not yet convinced that it's without problems ... ks
I'm not saying || ( ) is without problems - I'm saying versioned virtuals is broken :) Of course, they're not universally broken or they wouldn't be used in so many ebuilds. Whatever you choose to do, you can't generally solve Nathans problem using virtuals afaik unless you bind the virtual to specific versions which certainly has it's own set of problems. Maybe mixing virtuals and || ( ) is the best option until GLEP 37 is implemented. Anyway, just giving some ideas as Nathan asked me how to solve his problem.
Maybe you guys could make up a ghc-bin for amd64 (?). If not maybe you could mail me some instructions. Who did the build for ghc-6.2 ? I noticed an error in ghc-6.4 that has been fixed by now. Is there any way to get patches? I don`t have the time to figure out the patch from cvs tree Thanks !
You're right we should add amd64 to the ghc-bin-6.4 ebuild. As for the other fixes, we've been told that ghc 6.4.1 will be out soon (within a few weeks) so backporting the various fixes for amd64 is probably not a good use of our time at the moment but if 6.4.1 seems like is going to be a long time comming we'll re-evaluate that decision. Don't worry we do want to get ghc on amd64 working well too!
Would be great to have a ghc-bin-6.4, because on PPC there seems to be now way to install any ghc at the moment. ghc-bin-5.04.3 refuses to work, because it needs readline-4 where readline-5 is installed, and without that you can't get any other version of ghc to build.
ghc-6.4.1 is out, please update the portage (ghc-bin). http://www.haskell.org/ghc/download_ghc_641.html
ghc-bin-6.4.1 for amd64 is done. This leaves just ppc and ppc64. I'm cc'ing the ppc/ppc64 arch folk since it'd be nice to have the latest ghc-bin as we're going to try and get ghc-6.4.1-r2 marked stable on all arches in a few weeks. Quick guide to getting ghc-bin updated for an extra arch: --------------------------------------------------------- (substitute "arch" as appropriate) We have a script to help: http://haskell.org/~gentoo/gentoo-haskell/build-ghc-bin.sh use it like so: ACCEPT_KEYWORDS="~arch" ./build-ghc-bin.sh 6.4.1-r2 This will produce: /usr/portage/packages/All/ghc-6.4.1-r2.tbz2 mv that to: /usr/portage/distfiles/ghc-bin-6.4.1-arch.tbz2 * enable the appropriate arch bits in the ghc-bin-6.4.1.ebuild. * briefly check that ghc-bin-6.4.1.ebuild works at all * upload "ghc-bin-6.4.1-arch.tbz2" to dev.gentoo.org:/space/distfiles-local/ * commit the changes to ghc-bin-6.4.1.ebuild. (Note that while we're currently up to 6.4.1-r2 for ghc, we're at 6.4.1 for ghc-bin. That's ok; it's not a problem.)
Configure dies with this when running your script on ppc: configure: error: GHC is required unless bootstrapping from .hc files. Any suggestions?
ghc does depend on virtual/ghc which is provided by ghc and ghc-bin. So if you emerge -pv ghc portage should emerge ghc-bin first. If it's not doing that then it's bug in portage handling of virtuals (again). So since this portage bug seems to be back we're going to investigate moving to "new style" virtuals.
ppc done
It'd be great to get ghc-6.4.1 marked ~ppc64. We can be fairly sure it works since corsair fixed up ghc-6.4 and ghc-bin-6.4 some time ago. We just need someone with ppc64 hardware to test ghc-6.4.1 and the packages it depends on: haddock & cabal. (While ghc-bin-6.4 is ~ppc64, ghc-6.4 never got marked ~ppc64 because the packages it dependes on were never marked ~ppc64.) To save time in producing a .tbz2 package for ghc-bin-6.4.1, one could just follow the mini-guide in comment #20 rather than emerging =ghc-6.4.1 and then building a package. So only one full build of ghc is needed! I'd like to get this done soonish since we're hoping to get ghc-6.4.1 marked stable on all arches in a couple weeks. cc'ing corsair in case he has the time to try this.
Hi, I already took a small look into this and I found out that the package I built is a little bit broken: I somehow manged to build it with timestamps from year 40876 or something like that. So you get *many* 'timestamp is in future' warnings when installing ghc-bin.. ( yea! call me dump!! ;-) ) Anyway, the binary *should* work, even with broken timestamps, but I'm getting this error, while trying to build ghc using ghc-bin with your script: [...] Could not find module `System.Directory': [...] Unfortunaly I don't have much time for this at the moment as I'm writing my first tests at university this month. I'll definetly fix this when I get some spare time. So please be patient. ;-) Regards, Markus
cparrott found that the problem is that for arches that use lib64, the ghc-bin ebuild wasn't fixing the paths properly in ghc's package.conf database. A fix is now in portage. So hopefully this will fix the problem on ppc64. And it turns out that amd64 had the same problem! That should be fixed too.
Upon further investigation, it seems we have hit another snag with ghc on ppc64. While building cabal-1.1.3-r1 using ghc-bin-6.4.1, I get the following error: Compiling Distribution.Simple.SrcDist ( ./Distribution/Simple/SrcDist.hs, dist/build/Distribution/Simple/SrcDist.o ) Compiling Distribution.Simple ( ./Distribution/Simple.hs, dist/build/Distribution/Simple.o ) /usr/bin/ar: creating dist/build/libHSCabal-1.1.3.a /usr/bin/ld: TOC section size exceeds 64k !!! ERROR: dev-haskell/cabal-1.1.3-r1 failed. !!! Function cabal-build, Line 140, Exitcode 1 !!! setup build failed !!! If you need support, post the topmost build error, NOT this status message. The standard recommended fix for this seems to be to add -mminimal-toc to the gcc command-line, to generate a per-object file TOC. However, passing this flag to gcc via ghc's -optc-mminimal-toc flag yields the following error from ghc's mangler: mizar ~ # ghc -optc-mminimal-toc Hello.o Hello.hs Warning: retaining unknown function `.LCTOC0' in output from C compiler Warning: retaining unknown function `.LCTOC1 = .+32768' in output from C compiler Prologue junk?: .size s1oJ_entry,24 .type .s1oJ_entry,@function .s1oJ_entry: ld 30,.LCTOC0@toc(2) I believe the issue here is that the gcc on ppc64 produces additional prologue information in the assembly output when -mminimal-toc is passed in, which the ghc mangler does not know how to handle. I will look into patching ghc/driver/mangler/ghc-asm.lprl to handle this, but we should probably raise this issue with the upstream ghc developers for inclusion back into the mainline ghc sources. (If they have not already addressed it.) I believe this issue is not unique to cabal, but it may be seen with any large program on ppc64. For more details about this issue, please consult: http://www-128.ibm.com/developerworks/library/l-pow-gnutool/ Especially the section on binutils.
Correction: in my previous comment, I made a reference to ghc-bin-6.4.1. Since no such beast exists for ppc64, this should be ghc-bin-6.4. Sorry for any confusion.
I have managed to build an unregisterized version of ghc-6.4.1 for ppc64, and then I subsequently used it to successfully build cabal with '-fvia-C -optc-mminimal-toc' added to the command-line. We should probably have a discussion with the ghc developers about fixing the Evil Mangler for ppc64 when -optc-mminimal-toc is added to the ghc command line. I have successfully tested a bunch of haskell packages on ppc64 with this build. I will post my results in a separate bugzilla entry, so that Duncan can keyword them for ~ppc64.
I have entered new bugs for keywording various haskell packages and their dependencies with ~ppc64. Please see bug 124469 and bug 124470 for further information.
Upon further investigation, it appears that we can sidestep the issue involving the TOC overflow for cabal on ppc64 for the moment. The problem arose during the build of cabal-1.1.3, when it tried to build the cabal library for ghci. Since ghci is not yet supported on ppc64, this issue is moot at the moment. In the future, we may need to revisit this issue if ghci is enabled for ppc64, or if other haskell codes demonstrate a need to be compiled with -mminimal-toc. I have successfully bootstrapped a registerized build of ghc-6.4.1 on ppc64, and I will use Duncan's instructions above to create a ghc-bin-6.4.1 tarball of the same.
Chris: Thanks for the work you are doing to get haskel running on ppc64. :-) Unfortunaly there is no need to build that package you mentioned in the last comment, as I would build it myself anyway ( you know, there needs to be some kind of trust when building packages that are put in 'distfiles' ;-) ) Duncan: What would be the best way to let cabal be compiled with '-fvia-C -optc-mminimal-toc'? I'm not very familiar with build systems, but cabal's build system is not autotools, is it? So append-flags from flag-o-matic.eclass won't work. Can you give me a hint, please? ;-)
Markus: I believe it is no longer necessary to force '-fvia-C -optc-mminimal-toc' in ghc on ppc64, as the TOC overflow problem was limited to linking an object file which is not currently used on ppc64. Whenever ghci is enabled for ghc on ppc64, we may need to revisit this issue. -mminimal-toc should probably be passed on a per-package basis, though. Just the same, I shall defer to you to build and package ghc-bin-6.4.1 on ppc64 for distfiles. If I can be of any assistance, please feel free to ask.
(In reply to comment #32) > Duncan: What would be the best way to let cabal be compiled with '-fvia-C > -optc-mminimal-toc'? I'm not very familiar with build systems, but cabal's > build system is not autotools, is it? So append-flags from flag-o-matic.eclass > won't work. Can you give me a hint, please? ;-) What we need to do is to modify the haskell-cabal.eclass to get cabal to not build ghci libs on ppc64 (or indeed other arches where ghci doesn't work). + # Don't build GHCi libs for arches that do not support GHCi. + # Also building GHCi libs on ppc64 causes "TOC overflow". + if use alpha || use ppc64; then + cabalconf="${cabalconf} --disable-library-for-ghci" + fi Then that should make it work for all ebuilds that use cabal (including cabal itself). I will commit this change shortly.
hmm.. getting all emails from this bug twice.. removing me from CC as I'm already on ppc64@g.o
The ghc-bin package seems to have hit the mirrors. So I've added ~ppc64 to that ebuild and also to ghc/haddock/cabal! Thanks for help Chris and Duncan! Marking as FIXED as PPC64 was the last arch.
Great! Thanks Markus. I've also updated the haskell-cabal eclass so emerging cabalised packages should work ok on ppc64 - though this needs testing on a per-package basis. There are also several packages which do not use Cabal and these may fail with the TOC overflow problem when they create ghci libs. However this should mostly be fixable by changing the ghc-package eclass to make the ghc-makeghcilib function a no-op on ppc64 (and alpha).
