Re: pkg/41941: games/wesnoth - core dump from make, NetBSD 4.0

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR pkg/41941; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
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>
     Message-ID:  <20090827061505.1E47E63B850%www.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
 slightly).
 
 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
 investigate.
 
 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.]
 
 kre