On Sun, Jan 09, 2000 at 00:32:56 +, Ian Jackson wrote:
> Michael Weber writes ("Re: Deadlock again (was Re: GHC 4.04.19990916 produces
>coredumpin g executable)"):
> > New versions for Debian usually can be found on my site (see signature) at
> > first, the latest is ghc4_4.05.19991206-1.deb.
>
> Thanks, but the version Simon referred me to was from 1999-12-25. I
> tried to build it myself from the anonymous CVS but had some problems
> integrating the Debian patches - see below.
>
> Michael: obviously it would be best for me to use the Debian sources,
> but is it _necessary_ ? Ie, are there any changes you've made to
> problems which prevented the compiler from working ?
Sometimes, there are small glitches in the build process, which I correct,
furthermore some Debian specific things, but usually I report them back to
upstream. For instance, I already sent (most of) the patches in the
`debian/patches/' dir of my latest version to the mailing-list and SimonM
incorporated them (or at least had a look at them, and corrected the
problem somehow else).
BTW: because of the slw CVS the source tarballs are meant as snapshots,
too. And (as a QA means), I was able to build a compiler out of these
sources, that can build itself again.
> When were directory layout changes made to the source tree - ie, Michael,
> does the 4.05 version that you provide have the relevant changes so it will
> work reasonably with the pre-4.06 ?
yes, 19991206 already has the new library scheme.
> I get the feeling I'm thrashing around rather here. I'm currently
> downloading the 19991206.orig.tar.gz from your site at rwth-aachen, and
> will try that (and also try it after `cvs update' to the version Simon
> suggests). But, if it doesn't have the new directory structure then it's
> probably not much use to me.
It's definitely the better version (wrt. to building), since I
revamped the build process entirely. It's cleaner and easier now.
> Now, I could try to fix the problem properly and send you (Michael)
> the diffs, but I think it would take me some time to get used to the
> somewhat arcane build system in the Debian GHC package. If you could
> do it I'd appreciate it.
I'll have a look at it this week...
> Simon Marlow writes ("RE: Deadlock again (was Re: GHC 4.04.19990916 produces
>coredumping executable)"):
>> As for finding the location of a black-hole or infinite loop, there are two
>> techniques available. The first is to fire up your program in gdb, stop it
>> at the black hole, have a look at the stack and try to map what you find
>> there back on to the Haskell source (not an easy task :-).
yes, I can emphasize this, after having spent some hours in gdb... :-)
> Michael, here is what I did to get a non-working GHC 1999-12-25 .deb:
> First, I obtained ghc-4.04.19990916.orig.tar.gz and -3.{dsc,diff.gz}
...which was bad luck, since the new library scheme was introduced in
October/November, IIRC...
> Attempts to build it with `debian/rules build' and `fakeroot debian/rules
> binary' were not very successful. Firstly, there were a number of patches
> in debian/patches which were rejected. Is there some reason those weren't
> in the .diff.gz ?
In earlier Debian packages, I had the old scheme (patches in .diff.gz), but
I found the current patch strategy saving me some time. To me, it's more
convenient, since I can switch forth and back to the patched/unpatched
version of the sources, I just have to
$ debian/rules patch
[see, what's been rejected]
$ debian/rules unpatch
[copy a better patch in debian/patches/]
$ debian/rules patch
[repeat]
Also, I can disable patches temporarily by just renaming them...,
furthermore, I'm easily able to distinguish between debian-specific patches
and GHC-specific ones, which can be sent to upstream...
As you might have seen now: many many reasons for switching... ;-)
> I had to run autoconf by hand in each directory with a configure.in (with
> find -name configure.in | xargs -n1 sh -c ), and then
> was about to run debian/rules build to produce a build-stamp (this took
> perhaps 4 hours).
Nope, for me it always has been sufficient to
$ autoconf ; configure
in the root of the build tree (besides, there is a `debian/rules configure')
> It then failed because of the lack of an `fptools' directory. It looks
... `hslibs' ... ?
> like things have been reorganised substantially since the
> 4.04.19990916.orig.gz package. [...]
yes, this all should be solved with 19991206 already, see above.
Ok, as promised, I'll have a look at the X-Mas version of GHC.
Cheers,
Michael
--
Those who open their minds too far often let their brains fall out.
Those who open their minds too far often let their brains fall out.
Those who open their minds too far often let their braGeneral Protection Fault
in msborg32.dll.
