[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/41941: games/wesnoth - core dump from make, NetBSD 4.0
The following reply was made to PR pkg/41941; it has been noted by GNATS.
From: Robert Elz <kre%munnari.OZ.AU@localhost>
Subject: Re: pkg/41941: games/wesnoth - core dump from make, NetBSD 4.0
Date: Thu, 27 Aug 2009 18:59:51 +0700
Date: Thu, 27 Aug 2009 06:15:05 +0000 (UTC)
From: David Holland <dholland-pbugs%NetBSD.org@localhost>
| I suppose that might be difficult to do with pkg_comp.
Actually, it is fairly easy, just a bit tedious, and I can do that
if you really believe there's much benefit to be gained (that is, if
you really suspect there may be a fix needed to a 4.x version of make
that hasn't been pulled up yet).
But no matter what is discovered that way, it won't help with the problem
I have - I am compiling things on a 4.0 release system. That is set in
concrete from the day it was released, nothing in it can ever alter.
If there was something so bad about 4.0 that almost nothing would build
correctly, I'd just give up on it as a base, and move to 4.0.1 or 4.0_stable
of some date or other, or something like that - but that's not the case.
Nothing else (I have yet found) in pkgsrc (or elsewhere) is causing make to
dump core this way, and the previous version of wesnoth (before April 1 or
whenever) did not cause problems either - the bug must be fairly obscure,
so I suspect a better "fix" (workaround perhaps) will be to simply compensate
for the make bug (which I agree is what it looks to be) by simply avoiding
swinging whatever dead cat is causing this particular pain.
Now if just blindly compiling newer versions of make and testing them
to see if they work is going to help accomplish that. I'm certainly willing
to give it a go (though given that half the world has just been obliterated
by the jpeg caused revbump, it might take a while before I have everything
needed for wesnoth back in a functional state, so that might delay things
On the other hand, if looking to see what changed in wesnoth, that has
triggered the make bug might be a more productive investigation, then
maybe that would be a better place to look, it is clearly in the install
phase in the src section (other stuff had been installed already), so
I would (perhaps naively) hope that there shouldn't be too much to
If the cause of the make bug is found, then it will probably be obvious
whether the fix has been applied to current netbsd-4 (perhaps in 4.0.1
already), or if some pullup is still needed, and probably even which - that
is unless, of course, it reveals a previously unidentified make bug (which
is unlikely, as I assume that other people, with newer systems, can
successfully compile wesnoth, or this version would never have been committed,
or at least someone else would have complained in the intervening almost
5 months ... which is kind of what I had been hoping would have happened...)
What do you suggest?
[Absent other advice, my next step would probably be to build a version of
(4.0's) make with -g, and see if that will tell me exactly what part of the
wesnoth input (Makefiles) it is processing when it crashes, then I can go
and look and see what changed from the previous (working) version, and see
if some patch to wesnoth (to the Makefile in question) might allow things to
get a little further - if it turns out to be a place where wesnoth has added
make magic to allow it to correctly install on some other foreign system,
and that magic is causing the crash, then the patch can simply delete it,
we clearly managed Ok with what was there before.]
Main Index |
Thread Index |