Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 29 Oct 2009 17:50:22 -0500 (CDT)
From:      Scott Bennett <bennett@cs.niu.edu>
To:        bf1783@googlemail.com, freebsd-questions@freebsd.org
Subject:   Re: lang/gcc43 and lang/gcc44 installation procedures broken after updates
Message-ID:  <200910292250.n9TMoM3f027744@mp.cs.niu.edu>

next in thread | raw e-mail | index | archive | help
     On Thu, 29 Oct 2009 20:07:09 +0000 "b. f." <bf1783@googlemail.com>
wrote:
>On 10/29/09, Scott Bennett <bennett@cs.niu.edu> wrote:
>>      On Wed, 28 Oct 2009 09:19:08 +0000 "b. f." <bf1783@googlemail.com>
>> wrote:
>>>On 10/28/09, Scott Bennett <bennett@cs.niu.edu> wrote:
>>>>      On Tue, 27 Oct 2009 11:28:51 +0000 "b. f." <bf1783@googlemail.com>
>>>> wrote:
>>>>>Scott Bennet wrote:
>
>>>MAKE_JOBS_NUMBER?=      `${SYSCTL} -n kern.smp.cpus`
>>>_MAKE_JOBS=             -j${MAKE_JOBS_NUMBER}
>>
>>      I figured it must do something of the sort.  The CPU is an old 3.4 GHz
>> P4 Prescott, so it has two logical processors, so MAKE_JOBS_NUMBER gets set
>> to 2.  Given the handbook recommendations and my own observations, it seems
>> to me that the above method should actually multiply the value of
>> kern.smp.cpus by at least 2.5 for best performance.  For CPUs on separate
>> cores, 3 is the recommended multiplier, but where HTT logical CPUs are
>> involved a multiplier somewhat lower than that is in order.  On the Prescott
>> chips, 2.5 seems to work very well, so when I set MAKEFLAGS myself, I set
>> it to 5, which is 2.5 * kern.smp.scpus.
>>
>
>That seems a bit ambitious.  In any event, It would be better to do

     Perhaps it is, but my own experience with it shows 6 to be too high and
4 to be a bit low.  5 seems to work pretty well with very little CPU idle time.

>this via the variable MAKE_JOBS_NUMBER, which was created for this
>purpose and can be overridden by the user, rather than by using
>MAKEFLAGS, which may cause all sorts of problems, among them ignoring
>the setting of MAKE_JOBS_UNSAFE.

     When installing/updating ports, I always "unsetenv MAKEFLAGS" before
starting, so there should be no problem.  It just means that some ports
jobs probably take slightly longer to complete.
>
>>>
>>>> I guess I will just have to add "-x gcc\*" to the
>>>> "portmaster -x perl\*5.8.9\* -a" runs from now on, which is now possible
>>>> thanks to Doug Barton's portmaster enhancement that allows multiple "-x"
>>>> arguments, and do lang/gcc* updates by the old-fashioned method that
>>>> worked
>>>> in this case.  I'm not sure what to do if a situation arises like this
>>>> for
>>>> a port that has many dependencies that would typically be better managed
>>>> by
>>>> portmaster or portupgrade, however.
>>>
>>>You don't have to do it on the command line -- you can add the port to
>>>HOLD_PKGS in pkgtools.conf with portupgrade, or use a
>>
>>      I haven't been using portupgrade much lately.  portmaster seems to
>> be the recommended tool, and it's certainly a lot faster than portupgrade,
>
>portmaster is more lightweight, but has fewer features.  I roll my own.
>
     From just the few months I've been using portmaster, it seems to make
fewer mistakes than portupgrade, though.  The problem is in trying to keep
in mind that the mistakes that it does make are ones it makes quite frequently.
>>
>>
>>>/var/db/pkg/*/+IGNOREME as described in portmaster(8).  It's a bit of
>>
>>      Yes, but that method doesn't work for perl, and IIRC, it doesn't
>> work for lang/gcc?? either.  The -x method does, however.
>>
>
>It seems to work for me with lang/perl5.10.  What experience have you
>had that suggests that it doesn't work with these ports?
>
     I upgraded from lang/perl5.8 to lang/perl5.10 a few months ago.  The
thread should be in the freebsd-ports@ archives.  portmaster would prompt
about the +IGNOREME file, accept the reply of "n" or just hitting enter
to take the default of "n", continue on a while, and then begin to rebuild
perl-5.8.9 anyway.
     -x works more reliably than +IGNOREME, but the two together cover more
situations, so that's what I do now for the really tough cases like perl.
A problem until a month or two ago was that portmaster would only accept a
single -x argument.  Doug Barton enhanced it to accept many a couple of
months ago, so portmaster is a considerably better tool now than it was
before.  He has recently posted a request on freebsd-announce for funding
to support a major rewrite/enhancement project for portmaster.  If enough
money can be raised, he plans to drop his other income-producing activities
long enough to get the project done, which might reduce the frequency of
roadblocks we encounter in dealing with the ports subsystem of FreeBSD.


                                  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?200910292250.n9TMoM3f027744>