/opt/ghc/bin/ghc -ldl -cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -iutils:basicTypes:types:hsSyn:prelude:rename:typecheck:deSugar:coreSyn:specialise:simplCore:stranal:stgSyn:simplStg:codeGen:absCSyn:main:profiling:parser:usageSP:cprAnalysis:compMan:ndpFlatten:nativeGen -package concurrent -package posix -package util -recomp -Rghc-timing -H16M '-#include "hschooks.h"' -O -c utils/FastString.lhs -o utils/FastString.o utils/FastString.lhs:71: Module `CString' does not export `unpackNBytesBA#' <<ghc: 25056516 bytes, 7 GCs, 785186/1546636 avg/max bytes residency (2 samples), 25M in use, 0.00 INIT (0.00 elapsed), 0.18 MUT (0.25 elapsed), 0.09 GC (0.10 elapsed) :ghc>> Reproducible: Always Steps to Reproduce:
Hi Peter. Thanks for the report! Well, ghc-5.x is not supposed to be bootstrapped with ghc-6, so no real surprise here, except to show a slippage on our side :(. Andres: Apparently DEPEND of ghc should have been adjusted with the introduction of 6.0 version. Just putting =...-5* could work, although we have it as virtual/ghc and I am not sure this will work with virtuals. Also I don't think this is allowed :(, but if it works - go ahead, as I dont see another quick fix for this right now. We will need to bug portage people on this issue anyway... George
Unfortunately, a DEPEND="=virtual/ghc-5*" does not seem to work. On my machine, with both ghc-6.0.1 and ghc-bin-6.0 installed, an emerge =ghc-5.04.3-r1 then results in no dependencies at all. The "--debug" option shows that the ebuild ghc-5.04.3-r1 itself is supposed to fulfill the dependency, which is somewhat logical, because virtual/ghc on my machine resolves to dev-lang/ghc. I am coming to increasingly dislike the virtual/ghc hack we are using to bootstrap ghc at the moment. It relies on too many portage features which are at the border of being supported. This is an idea, and I would appreciate comments: Remove the ghc-bin ebuild. Instead, let the ghc ebuild itself download a binary to bootstrap if no *suitable* version of ghc is present on the system (can be checked without a dependency, using has_version). The binary is only temporarily used for the bootstrap and then discarded. The ebuild could provide local use flags to force installing the binary directly or to force bootstrapping from the binary even though a suitable ghc is present on the system. It would solve this bug, keep the functionality of installing the binary and saving time this way (via USE flag), and recude the overall fragility by removing the need for virtual/ghc. What do you think?
I have removed ghc-5.04.3 from portage, so this should no longer be relevant.
