On Wed, Aug 01, 2007 at 03:53:36PM +0200, steven mestdagh wrote:
> > this should fix breakage for amd64 on the following ports:
> >
> > devel/alex
> > devel/haddock
> > devel/happy
> > devel/hs-newbinary
> > security/hs-crypto
> >
> > I also replaced WRKSRC by WRKBUILD where appropriate, so that
> > SEPARATE_BUILD *may* be used in a (very far) future. Currently,
> > SEPARATE_BUILD doesn't work at all with Haskell ports using Cabal
> > (i.e. that Setup.{,l}hs stuff).
> >
> > No pkgbump required, since on i386 nothing changed, and on amd64
> > the ports didn't build yet.
>
> But they built before ghc was updated... so maybe it's safe to bump in any
> case.
IIRC all of them have been updated to new versions together with
the GHC update. I'll check this, and should any one still have the
same version as before the GHC update, I'll bump it.
> > I'd really appreciate any tests on amd64 (does it build? regress
> > output where regress isn't a noop? any packaging problems?). Some
> > porters where interested but don't have enough time to test this.
>
> They build fine with these changes. No regressions in happy and hs-crypto,
> the others have NO_REGRESS.
Thanks for running the builds!
> However, something must be wrong with the runhaskell program?
Yes, unfortunately it's broken for the same reason ghci is broken:
GHC comes with it's own linker that (for ghci and runhaskell) tries
to load object files at runtime. This doesn't currently work on
amd64.
I'm not absolutely sure, but the problem may be this: On Linux, the
GHC linker uses a special (non-portable) flag, MAP_32BIT, to mmap(2)
to force mmap(2) to only return addresses in the lower address
space.
I don't (yet) know enough about the inner guts of GHC to fix this.
Please note that at least ghci didn't work at all before the update,
not even on i386.
Ciao,
Kili
