Date: Tue, 4 Aug 2009 02:50:43 -0500 (CDT) From: Scott Bennett <bennett@cs.niu.edu> To: dougb@FreeBSD.org Cc: skv@freebsd.org, freebsd-ports@freebsd.org Subject: Re: recent update causes perl5.10 build failure Message-ID: <200908040750.n747ohUB021532@mp.cs.niu.edu>
next in thread | raw e-mail | index | archive | help
On Mon, 03 Aug 2009 12:24:10 -0700 Doug Barton <dougb@FreeBSD.org>
wrote:
>Scott Bennett wrote:
>> An update yesterday or today results in perl5.10's build aborting. When
>> it failed under portmaster, the messages from several processes were too
>> jumbled for me to see easily what had happened, so I tried portinstall instead.
>
>If you get a non-obvious port build failure in portmaster your next
>step should be to try just building the port itself without any tools
>(i.e., cd /usr/ports/foo/bar ; make clean ; make). That will give you
>the idea of whether or not the error is related to the tool, or the
>port itself.
Okay. I'll keep that in mind for the future. However, in this case,
I recognized some symptoms of a port that is not safe for a parallel make:
errors complaining about missing directories and other files, etc.
>
>> At least on a first look, it seems that perl5.10 has "MAKE_JOBS_SAFE= yes"
>> in its Makefile, but that it should not. I changed that to
>> "MAKE_JOBS_SAFE= no"
>
>The ports infrastructure does not care what the value of the define
>is, it just cares if it is defined. You need to do this:
>
>cd /usr/ports/lang/perl5.10
>vi Makefile (replace the MAKE_JOBS_SAFE with MAKE_JOBS_UNSAFE)
>make clean
>make config
>make
That's interesting, but in this case, I changed it as I noted before,
after which it built fine under the control of a tool. It is conceivable,
of course, that the timing of the processes involved varied enough from
the first failure to the time it finally worked that it just happened to
have everything already created by the time it was needed. My recollection,
though, is that it appeared to be doing a serial make after I made the change
from "yes" to "no". But I will know not to expect that in the future and
will use MAKE_JOBS_UNSAFE. That having been said, the port still needs to be
fixed either by a) making the variable replacement you suggest or b) changing
the port to make sure things happen in the proper order even when a parallel
make is used.
Keep in mind that this experience did appear to reveal a portmaster bug.
After the "portmaster -w -v -a" had already asked whether to rebuild perl5.8
even though it had a +IGNOREME file and had gotten an enter key in response,
which should have selected the "n" shown as the default ("[n]"), it later
went ahead and built perl5.8 anyway. From what you and the documentation
have told me, that should never happen.
>
>Then report your results.
>
Yes. Again, in this particular case, that report was both possible and
made without resort to the procedure you outlined.
Thanks for the information and suggestions, Doug.
Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet: bennett at cs.niu.edu *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
* -- Gov. John Hancock, New York Journal, 28 January 1790 *
**********************************************************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200908040750.n747ohUB021532>