lang/gcc43 and lang/gcc44 installation procedures broken after updates

[Henry Olyer]

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 at cs.niu.edu> wrote:

>     On Thu, 29 Oct 2009 20:07:09 +0000 "b. f." <bf1783 at googlemail.com>
> wrote:
> >On 10/29/09, Scott Bennett <bennett at cs.niu.edu> wrote:
> >>      On Wed, 28 Oct 2009 09:19:08 +0000 "b. f." <bf1783 at googlemail.com>
> >> wrote:
> >>>On 10/28/09, Scott Bennett <bennett at cs.niu.edu> wrote:
> >>>>      On Tue, 27 Oct 2009 11:28:51 +0000 "b. f." <
> bf1783 at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "
> freebsd-questions-unsubscribe at freebsd.org"
>