Date: Thu, 29 Oct 2009 19:19:28 -0400 From: Henry Olyer <henry.olyer@gmail.com> To: Scott Bennett <bennett@cs.niu.edu> Cc: bf1783@googlemail.com, freebsd-questions@freebsd.org Subject: Re: lang/gcc43 and lang/gcc44 installation procedures broken after updates Message-ID: <1d7089c40910291619y27045d23pae9ba9d98db9f086@mail.gmail.com> In-Reply-To: <200910292250.n9TMoM3f027744@mp.cs.niu.edu> References: <200910292250.n9TMoM3f027744@mp.cs.niu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Look, keep claiming that it's working if you like, but I've been backing up
another machine and making notes -- so that when I do my reinstall of 7.2, I
don't have to come back here again, asking for help that's already been
given.
My point is: gcc44 doesn't work. It is broken and I suspect it's going to
stay broken. Only a fresh install *might* fix the problem.
I know these systems are very complex, I don't want to criticize anyone --
I'm very impressed that the FreeBSD community works as well as it does; And
after all, this is the first time I've encountered problems this serious,
and I used to write compilers, so I know that you guys have done a terrific
job.
But let's move on; gcc44 doesn't work, it's not going to, and we need to
focus on a repair strategy. Is it to simply to do a fresh install? I've
been backing up, I'll do this if I have to...
On Thu, Oct 29, 2009 at 6:50 PM, Scott Bennett <bennett@cs.niu.edu> wrote:
> 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 *
> **********************************************************************
> _______________________________________________
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "
> freebsd-questions-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1d7089c40910291619y27045d23pae9ba9d98db9f086>