Re: lang/gcc43 and lang/gcc44 installation procedures broken after updates
On 10/29/09, Scott Bennett benn...@cs.niu.edu wrote:
On Wed, 28 Oct 2009 09:19:08 + b. f. bf1...@googlemail.com
wrote:
On 10/28/09, Scott Bennett benn...@cs.niu.edu wrote:
On Tue, 27 Oct 2009 11:28:51 + b. f. bf1...@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
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.
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.
/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?
b.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: lang/gcc43 and lang/gcc44 installation procedures broken after updates
On Thu, 29 Oct 2009 20:07:09 + b. f. bf1...@googlemail.com
wrote:
On 10/29/09, Scott Bennett benn...@cs.niu.edu wrote:
On Wed, 28 Oct 2009 09:19:08 + b. f. bf1...@googlemail.com
wrote:
On 10/28/09, Scott Bennett benn...@cs.niu.edu wrote:
On Tue, 27 Oct 2009 11:28:51 + b. f. bf1...@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
Re: lang/gcc43 and lang/gcc44 installation procedures broken after updates
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 benn...@cs.niu.edu wrote:
On Thu, 29 Oct 2009 20:07:09 + b. f. bf1...@googlemail.com
wrote:
On 10/29/09, Scott Bennett benn...@cs.niu.edu wrote:
On Wed, 28 Oct 2009 09:19:08 + b. f. bf1...@googlemail.com
wrote:
On 10/28/09, Scott Bennett benn...@cs.niu.edu wrote:
On Tue, 27 Oct 2009 11:28:51 + b. f.
bf1...@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
Re: lang/gcc43 and lang/gcc44 installation procedures broken after updates
On Thu, 29 Oct 2009 19:19:28 -0400 Henry Olyer henry.ol...@gmail.com wrote: 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. Given that it has just finished compiling math/octave-3.2.3 in the last minute or two, I'd say your assessment of gcc44 needs some modification. :-) 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 It does work. 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... And it installed fine, too, which you would have known if you had read my followup to the suggestion to do a make distclean install from the lang/gcc44 directory, rather than to install it via portmaster. Assuming that the old-fashioned method handled any accumulated patches properly, then I think the only problem is in portmaster, rather than lang/gcc4[34]. What, in particular, about those two ports caused portmaster to screw up remains to be determined. 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-unsubscr...@freebsd.org
Re: lang/gcc43 and lang/gcc44 installation procedures broken after updates
On Tue, 27 Oct 2009 11:28:51 + b. f. bf1...@googlemail.com wrote: Scott Bennet wrote: There haven't been much changes in the infrastructure of these two ports recently, so any problems are probably arising from changes in the distfiles, or problems in your base system or the ports that are used to build and install lang/gcc4X. I'm running 7.2-STABLE. With one exception, I do not alter the contents of the ports tree manually. That exception is either math/atlas or math/atlas-devel, depending upon which I install. After installing 7.2 several months ago, I installed math/atlas-devel, which built properly all by itself without requiring any of the manual tweaking that earlier versions had required, so since switching from 6.3-STABLE to 7.2-STABLE, I have not made alterations to any ports in the ports tree by hand. Any changes that may have occurred would have to have happened during runs of portmaster, portupgrade, or make(1) (as in make deinstall make reinstall or some other standard use of make for a port). After seeing both lang/gcc43 and lang/gcc44 fail in exactly the same way, and then seeing another port fail in what appeared to be a similar way a few days later, I resorted to a portsnap fetch extract in case something in my ports tree *had* gotten screwed up somehow. Rerunning portmaster afterward yielded the same results. =3D=3D=3D Starting check for runtime dependencies =3D=3D=3D Gathering dependency list for lang/gcc43 from ports =3D=3D=3D Starting dependency check =3D=3D=3D Checking dependency: converters/libiconv =3D=3D=3D Checking dependency: math/libgmp4 =3D=3D=3D Checking dependency: math/mpfr =3D=3D=3D Dependency check complete for lang/gcc43 /bin/rm -f /usr/local/man/man7/fsf-funding.7 /usr/local/man/man7/gfdl.7 /= usr/local/man/man7/gpl.7 Something is very wrong here. portmaster should now be running 'make install', but the build transcript shows messages of the post-install target first, and then messages of the do-install target afterwards. Obviously this is going to lead to problems if it represents the true order in which commands were executed. Did you mangle the transcript, or does it faithfully represent the order in which things occurred? The only change I made was indicated by a comment that showed where a lot of lines were deleted. If you really want all that junk, which contained no error messages, I do still have it and can send it to you. Nothing was rearranged into a different order, however. If the latter, are you running a parallel build? If so, don't. Try I do not have MAKEFLAGS set when running portmaster or portupgrade. If a particular port decides internally to run a parallel make, it appears to do it as -j2. It appears that the lang/gcc?? ports work this way, too. starting from scratch, using only a single make job at any given time. Start from a clean WRKDIR, and remove portmaster from consideration, by using a simple 'make deinstall clean install' (backup your existing lang/gcc4X installation first if you so desire with 'pkg_create -b'.) portmaster long since created a backup package and deinstalled the ports in question. What happens? Surprise, surprise! It worked for lang/gcc43, which proceeded through a successful installation. I also tried the same for lang/gcc44, and it, too, built and installed successfully. Thank you very much for the suggestion. I cannot begin to imagine why it worked this way, but refused to work under portmaster or portupgrade. 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. I guess next I'll try running portmaster as shown above and see what else might fail, now that I have two and a half weeks of ports updates accumulated but not yet processed. :-) Thanks again for the suggestion! 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
Re: lang/gcc43 and lang/gcc44 installation procedures broken after updates
On 10/28/09, Scott Bennett benn...@cs.niu.edu wrote:
On Tue, 27 Oct 2009 11:28:51 + b. f. bf1...@googlemail.com
wrote:
Scott Bennet wrote:
...
With one exception, I do not alter the
contents of the ports tree manually.
...
I have not made alterations to any ports in the ports tree by hand. Any
changes that may have occurred would have to have happened during runs of
portmaster, portupgrade, or make(1) (as in make deinstall make
reinstall
...
I resorted to a portsnap fetch extract in case something
in my ports tree *had* gotten screwed up somehow.
Right, I wasn't suggesting it was necessarily due to local changes to
the Ports tree, although on the face of it that was possible, but that
it may also have failed because, once in a while, binaries and other
files belonging to the base system or ports get corrupted, and
malfunction. This is usually due to hardware problems, user error,
and occasionally, an OS or third-party software bug. The lang/gcc4?
ports are lengthy and demanding builds, and are among the most likely
to fail if such problems exist.
...
The only change I made was indicated by a comment that showed where
a lot of lines were deleted. If you really want all that junk, which
contained no error messages, I do still have it and can send it to you.
Nothing was rearranged into a different order, however.
You may want to save it, so that it will be available if anyone
decides to try to track down the problem.
I do not have MAKEFLAGS set when running portmaster or portupgrade.
If a particular port decides internally to run a parallel make, it appears
to do it as -j2. It appears that the lang/gcc?? ports work this way, too.
If parallel builds are not disabled in a port Makefile, or by you, and
you have a multiple-cpu or multiple-core machine, then
ports/Mk/bsd.port.mk uses:
# Multiple make jobs support
.if defined(DISABLE_MAKE_JOBS) || defined(MAKE_JOBS_UNSAFE)
_MAKE_JOBS= #
.else
.if defined(MAKE_JOBS_SAFE) || defined(FORCE_MAKE_JOBS)
MAKE_JOBS_NUMBER?= `${SYSCTL} -n kern.smp.cpus`
_MAKE_JOBS= -j${MAKE_JOBS_NUMBER}
.if defined(FORCE_MAKE_JOBS)
BUILD_FAIL_MESSAGE+=You have chosen to use multiple make jobs
(parallelization) for all ports. This port was not tested for this
setting. Please remove FORCE_MAKE_JOBS and retry the build before
reporting the failure to the maintainer.
.endif
.endif
.endif
to do a parallel build. Since this feature is relatively new, and
people are occasionally finding that it breaks port builds, then it is
an obvious thing to try disabling in a case like this, where you have
a demanding build, and some evidence that things are being done out of
the proper order. In the future, you can disable this feature for a
build by setting DISABLE_MAKE_JOBS=yes on the make command line, in
the build environment, or in /etc/make.conf, e.g.:
.if${.CURDIR:M*/usr/ports/lang/gcc44*}
DISABLE_MAKE_JOBS=yes
.endif
portmaster long since created a backup package and deinstalled the
ports in question.
Ok. I don't use portmaster often, but portupgrade will often restore
an old installation of the port from the backup package automatically
after a failure.
...
I cannot begin to imagine why
it worked this way, but refused to work under portmaster or portupgrade.
Occasionally a port exposes a bug in portmaster or portupgrade. This
may be such a case, especially since Doug Barton made some recent
changes to portmaster. But the most common reason for failure is that
many ports, to enable easy maintenance, use sloppy flags like
LDFLAGS=-L${LOCALBASE}/lib or CPPFLAGS=-I${LOCALBASE}/include, that
may lead them to link against the older, already installed versions of
themselves, or to include old versions of their own headers if they
are present in the system. So it's always safer to deinstall a port
_before_ attempting to build it, or to build the port in a clean
sandbox as is done on many package-building clusters. portmaster and
portupgrade choose not to do this, in order to shorten the process of
recovering from a failed build, and to minimize the time during which
a piece of software is unavailable to users, and this can lead to
problems. I don't say that this happened in this case, but it is a
possibility.
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
/var/db/pkg/*/+IGNOREME as described in portmaster(8). It's a bit of
a pain to manage large updates -- you
Re: lang/gcc43 and lang/gcc44 installation procedures broken after updates
On Wed, 28 Oct 2009 09:19:08 + b. f. bf1...@googlemail.com
wrote:
On 10/28/09, Scott Bennett benn...@cs.niu.edu wrote:
On Tue, 27 Oct 2009 11:28:51 + b. f. bf1...@googlemail.com
wrote:
Scott Bennet wrote:
...
With one exception, I do not alter the
contents of the ports tree manually.
...
I have not made alterations to any ports in the ports tree by hand. Any
changes that may have occurred would have to have happened during runs of
portmaster, portupgrade, or make(1) (as in make deinstall make
reinstall
...
I resorted to a portsnap fetch extract in case something
in my ports tree *had* gotten screwed up somehow.
Right, I wasn't suggesting it was necessarily due to local changes to
the Ports tree, although on the face of it that was possible, but that
it may also have failed because, once in a while, binaries and other
files belonging to the base system or ports get corrupted, and
malfunction. This is usually due to hardware problems, user error,
and occasionally, an OS or third-party software bug. The lang/gcc4?
ports are lengthy and demanding builds, and are among the most likely
to fail if such problems exist.
Yes, they are heavy-duty constructions. perl also tends to be huge
and complex.
...
The only change I made was indicated by a comment that showed where
a lot of lines were deleted. If you really want all that junk, which
contained no error messages, I do still have it and can send it to you.
Nothing was rearranged into a different order, however.
You may want to save it, so that it will be available if anyone
decides to try to track down the problem.
I'll hang onto it for a while, but will eventually get rid of it
if no one wants it before I get around to deleting it in a few weeks
or so.
I do not have MAKEFLAGS set when running portmaster or portupgrade.
If a particular port decides internally to run a parallel make, it appears
to do it as -j2. It appears that the lang/gcc?? ports work this way, too.
If parallel builds are not disabled in a port Makefile, or by you, and
you have a multiple-cpu or multiple-core machine, then
ports/Mk/bsd.port.mk uses:
# Multiple make jobs support
.if defined(DISABLE_MAKE_JOBS) || defined(MAKE_JOBS_UNSAFE)
_MAKE_JOBS= #
.else
.if defined(MAKE_JOBS_SAFE) || defined(FORCE_MAKE_JOBS)
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.
.if defined(FORCE_MAKE_JOBS)
BUILD_FAIL_MESSAGE+=You have chosen to use multiple make jobs
(parallelization) for all ports. This port was not tested for this
setting. Please remove FORCE_MAKE_JOBS and retry the build before
reporting the failure to the maintainer.
.endif
.endif
.endif
to do a parallel build. Since this feature is relatively new, and
people are occasionally finding that it breaks port builds, then it is
an obvious thing to try disabling in a case like this, where you have
a demanding build, and some evidence that things are being done out of
the proper order. In the future, you can disable this feature for a
build by setting DISABLE_MAKE_JOBS=yes on the make command line, in
the build environment, or in /etc/make.conf, e.g.:
.if${.CURDIR:M*/usr/ports/lang/gcc44*}
DISABLE_MAKE_JOBS=yes
.endif
portmaster long since created a backup package and deinstalled the
ports in question.
Ok. I don't use portmaster often, but portupgrade will often restore
an old installation of the port from the backup package automatically
after a failure.
...
I cannot begin to imagine why
it worked this way, but refused to work under portmaster or portupgrade.
Occasionally a port exposes a bug in portmaster or portupgrade. This
may be such a case, especially since Doug Barton made some recent
changes to portmaster. But the most common reason for failure is that
many ports, to enable easy maintenance, use sloppy flags like
LDFLAGS=-L${LOCALBASE}/lib or CPPFLAGS=-I${LOCALBASE}/include, that
may lead them to link against the older, already installed versions of
themselves, or to include old versions of their own headers if they
are present in the system. So it's always safer to deinstall a port
_before_ attempting to build it, or to build the port in a clean
sandbox as is done on many package-building clusters. portmaster and
portupgrade choose not to do this, in
lang/gcc43 and lang/gcc44 installation procedures broken after updates
On Thursday about two and a half weeks ago, updates came through for lang/gcc43 and lang/gcc44 that resulted in broken installation procedures, although both ports appeared to build correctly. Here are the relevant messages from lang/gcc43. (lang/gcc44 appeared to fail installation in exactly the same way, except for gcc44 appearing where gcc43 appears in the output shown here. I noticed that a day or two later lang/gcc45 was also updated, but because I did not have that port installed, I do not know whether it may also have been broken. I see also that a new update for lang/gcc45 has come out in the last couple of days. === Starting check for runtime dependencies === Gathering dependency list for lang/gcc43 from ports === Starting dependency check === Checking dependency: converters/libiconv === Checking dependency: math/libgmp4 === Checking dependency: math/mpfr === Dependency check complete for lang/gcc43 /bin/rm -f /usr/local/man/man7/fsf-funding.7 /usr/local/man/man7/gfdl.7 /usr/local/man/man7/gpl.7 install-info --quiet /usr/local/info/gcc43/cpp.info /usr/local/info/dir install-info: No such file or directory for /usr/local/info/gcc43/cpp.info *** Error code 1 /bin/rm -f /usr/local/lib/gcc43/*.la # Add target libraries and include files to packaging list. /bin/rm -f /usr/ports/lang/gcc43/work/PLIST.lib cd /usr/local ; if [ -d lib/gcc43 ]; then /usr/bin/find lib/gcc43 -type f -o -type l /usr/ports/lang/gcc43/work/PLIST.lib ; /usr/bin/find lib/gcc43 -type d | /usr/bin/sort -r | /usr/bin/sed -e 's/^/@dirrm /g' /usr/ports/lang/gcc43/work/PLIST.lib ; fi cd /usr/local ; if [ -d libexec/gcc43 ]; then /usr/bin/find libexec/gcc43 -type f -o -type l /usr/ports/lang/gcc43/work/PLIST.lib ; /usr/bin/find libexec/gcc43 -type d | /usr/bin/sort -r | /usr/bin/sed -e 's/^/@dirrm /g' /usr/ports/lang/gcc43/work/PLIST.lib ; fi cd /usr/local ; if [ -d include/gcj ]; then /usr/bin/find include/gcj -type f -o -type l /usr/ports/lang/gcc43/work/PLIST.lib ; /usr/bin/find include/gcj -type d | /usr/bin/sort -r | /usr/bin/sed -e 's/^/@dirrm /g' /usr/ports/lang/gcc43/work/PLIST.lib ; fi cd /usr/local ; if [ -d include/gnu ]; then /usr/bin/find include/gnu -type f -o -type l /usr/ports/lang/gcc43/work/PLIST.lib ; /usr/bin/find include/gnu -type d | /usr/bin/sort -r | /usr/bin/sed -e 's/^/@dirrm /g' /usr/ports/lang/gcc43/work/PLIST.lib ; fi cd /usr/local ; if [ -d include/java ]; then /usr/bin/find include/java -type f -o -type l /usr/ports/lang/gcc43/work/PLIST.lib ; /usr/bin/find include/java -type d | /usr/bin/sort -r | /usr/bin/sed -e 's/^/@dirrm /g' /usr/ports/lang/gcc43/work/PLIST.lib ; fi cd /usr/local ; if [ -d include/javax ]; then /usr/bin/find include/javax -type f -o -type l /usr/ports/lang/gcc43/work/PLIST.lib ; /usr/bin/find include/javax -type d | /usr/bin/sort -r | /usr/bin/sed -e 's/^/@dirrm /g' /usr/ports/lang/gcc43/work/PLIST.lib ; fi cd /usr/ports/lang/gcc43/work ; /usr/bin/sed -i -e /PLIST.lib/ r PLIST.lib /usr/ports/lang/gcc43/work/.PLIST.mktmp sed: /usr/ports/lang/gcc43/work/.PLIST.mktmp: No such file or directory *** Error code 1 gmake[1]: Entering directory `/usr/ports/lang/gcc43/work/build' /bin/sh ./../gcc-4.3-20091004/mkinstalldirs /usr/local /usr/local gmake[2]: Entering directory `/usr/ports/lang/gcc43/work/build/libdecnumber' gmake[2]: Nothing to be done for `install'. gmake[2]: Leaving directory `/usr/ports/lang/gcc43/work/build/libdecnumber' gmake[2]: Entering directory `/usr/ports/lang/gcc43/work/build/intl' gmake[2]: Nothing to be done for `install'. gmake[2]: Leaving directory `/usr/ports/lang/gcc43/work/build/intl' gmake[2]: Entering directory `/usr/ports/lang/gcc43/work/build/fixincludes' rm -rf /usr/local/libexec/gcc43/gcc/i386-portbld-freebsd7.2/4.3.5/install-tools /bin/sh .././../gcc-4.3-20091004/fixincludes/../mkinstalldirs /usr/local/libexec/gcc43/gcc/i386-portbld-freebsd7.2/4.3.5/install-tools mkdir /usr/local/libexec/gcc43 mkdir /usr/local/libexec/gcc43/gcc mkdir /usr/local/libexec/gcc43/gcc/i386-portbld-freebsd7.2 mkdir /usr/local/libexec/gcc43/gcc/i386-portbld-freebsd7.2/4.3.5 mkdir /usr/local/libexec/gcc43/gcc/i386-portbld-freebsd7.2/4.3.5/install-tools /bin/sh .././../gcc-4.3-20091004/fixincludes/../mkinstalldirs /usr/local/lib/gcc43/gcc/i386-portbld-freebsd7.2/4.3.5/install-tools/include mkdir /usr/local/lib/gcc43 mkdir /usr/local/lib/gcc43/gcc gmake[2]: Entering directory `/usr/ports/lang/gcc43/work/build/i386-portbld-freebsd7.2/libstdc++-v3' Making install in include mkdir /usr/local/lib/gcc43/gcc/i386-portbld-freebsd7.2 mkdir /usr/local/lib/gcc43/gcc/i386-portbld-freebsd7.2/4.3.5 mkdir /usr/local/lib/gcc43/gcc/i386-portbld-freebsd7.2/4.3.5/install-tools mkdir /usr/local/lib/gcc43/gcc/i386-portbld-freebsd7.2/4.3.5/install-tools/include install -o root -g wheel -m 444 .././../gcc-4.3-20091004/fixincludes/README-fixinc \ /usr/local/lib/gcc43/gcc/i386-portbld-freebsd7.2/4.3.5/install-tools/include/README install -o
Re: lang/gcc43 and lang/gcc44 installation procedures broken after updates
Scott Bennet wrote: There haven't been much changes in the infrastructure of these two ports recently, so any problems are probably arising from changes in the distfiles, or problems in your base system or the ports that are used to build and install lang/gcc4X. === Starting check for runtime dependencies === Gathering dependency list for lang/gcc43 from ports === Starting dependency check === Checking dependency: converters/libiconv === Checking dependency: math/libgmp4 === Checking dependency: math/mpfr === Dependency check complete for lang/gcc43 /bin/rm -f /usr/local/man/man7/fsf-funding.7 /usr/local/man/man7/gfdl.7 /usr/local/man/man7/gpl.7 Something is very wrong here. portmaster should now be running 'make install', but the build transcript shows messages of the post-install target first, and then messages of the do-install target afterwards. Obviously this is going to lead to problems if it represents the true order in which commands were executed. Did you mangle the transcript, or does it faithfully represent the order in which things occurred? If the latter, are you running a parallel build? If so, don't. Try starting from scratch, using only a single make job at any given time. Start from a clean WRKDIR, and remove portmaster from consideration, by using a simple 'make deinstall clean install' (backup your existing lang/gcc4X installation first if you so desire with 'pkg_create -b'.) What happens? b. install-info --quiet /usr/local/info/gcc43/cpp.info /usr/local/info/dir install-info: No such file or directory for /usr/local/info/gcc43/cpp.info *** Error code 1 /bin/rm -f /usr/local/lib/gcc43/*.la # Add target libraries and include files to packaging list. /bin/rm -f /usr/ports/lang/gcc43/work/PLIST.lib cd /usr/local ; if [ -d lib/gcc43 ]; then /usr/bin/find lib/gcc43 -type f -o -type l /usr/ports/lang/gcc43/work/PLIST.lib ; /usr/bin/find lib/gcc43 -type d | /usr/bin/sort -r | /usr/bin/sed -e 's/^/@dirrm /g' /usr/ports/lang/gcc43/work/PLIST.lib ; fi cd /usr/local ; if [ -d libexec/gcc43 ]; then /usr/bin/find libexec/gcc43 -type f -o -type l /usr/ports/lang/gcc43/work/PLIST.lib ; /usr/bin/find libexec/gcc43 -type d | /usr/bin/sort -r | /usr/bin/sed -e 's/^/@dirrm /g' /usr/ports/lang/gcc43/work/PLIST.lib ; fi cd /usr/local ; if [ -d include/gcj ]; then /usr/bin/find include/gcj -type f -o -type l /usr/ports/lang/gcc43/work/PLIST.lib ; /usr/bin/find include/gcj -type d | /usr/bin/sort -r | /usr/bin/sed -e 's/^/@dirrm /g' /usr/ports/lang/gcc43/work/PLIST.lib ; fi cd /usr/local ; if [ -d include/gnu ]; then /usr/bin/find include/gnu -type f -o -type l /usr/ports/lang/gcc43/work/PLIST.lib ; /usr/bin/find include/gnu -type d | /usr/bin/sort -r | /usr/bin/sed -e 's/^/@dirrm /g' /usr/ports/lang/gcc43/work/PLIST.lib ; fi cd /usr/local ; if [ -d include/java ]; then /usr/bin/find include/java -type f -o -type l /usr/ports/lang/gcc43/work/PLIST.lib ; /usr/bin/find include/java -type d | /usr/bin/sort -r | /usr/bin/sed -e 's/^/@dirrm /g' /usr/ports/lang/gcc43/work/PLIST.lib ; fi cd /usr/local ; if [ -d include/javax ]; then /usr/bin/find include/javax -type f -o -type l /usr/ports/lang/gcc43/work/PLIST.lib ; /usr/bin/find include/javax -type d | /usr/bin/sort -r | /usr/bin/sed -e 's/^/@dirrm /g' /usr/ports/lang/gcc43/work/PLIST.lib ; fi cd /usr/ports/lang/gcc43/work ; /usr/bin/sed -i -e /PLIST.lib/ r PLIST.lib /usr/ports/lang/gcc43/work/.PLIST.mktmp sed: /usr/ports/lang/gcc43/work/.PLIST.mktmp: No such file or directory *** Error code 1 gmake[1]: Entering directory `/usr/ports/lang/gcc43/work/build' /bin/sh ./../gcc-4.3-20091004/mkinstalldirs /usr/local /usr/local gmake[2]: Entering directory `/usr/ports/lang/gcc43/work/build/libdecnumber' gmake[2]: Nothing to be done for `install'. gmake[2]: Leaving directory `/usr/ports/lang/gcc43/work/build/libdecnumber' gmake[2]: Entering directory `/usr/ports/lang/gcc43/work/build/intl' gmake[2]: Nothing to be done for `install'. gmake[2]: Leaving directory `/usr/ports/lang/gcc43/work/build/intl' gmake[2]: Entering directory `/usr/ports/lang/gcc43/work/build/fixincludes' rm -rf /usr/local/libexec/gcc43/gcc/i386-portbld-freebsd7.2/4.3.5/install-tools /bin/sh .././../gcc-4.3-20091004/fixincludes/../mkinstalldirs /usr/local/libexec/gcc43/gcc/i386-portbld-freebsd7.2/4.3.5/install-tools mkdir /usr/local/libexec/gcc43 mkdir /usr/local/libexec/gcc43/gcc mkdir /usr/local/libexec/gcc43/gcc/i386-portbld-freebsd7.2 mkdir /usr/local/libexec/gcc43/gcc/i386-portbld-freebsd7.2/4.3.5 mkdir /usr/local/libexec/gcc43/gcc/i386-portbld-freebsd7.2/4.3.5/install-tools /bin/sh .././../gcc-4.3-20091004/fixincludes/../mkinstalldirs /usr/local/lib/gcc43/gcc/i386-portbld-freebsd7.2/4.3.5/install-tools/include mkdir /usr/local/lib/gcc43 mkdir /usr/local/lib/gcc43/gcc gmake[2]: Entering directory `/usr/ports/lang/gcc43/work/build/i386-portbld-freebsd7.2/libstdc++-v3' Making install in include mkdir /usr/local/lib/gcc43/gcc/i386-portbld-freebsd7.2
