Re: lang/gcc43 and lang/gcc44 installation procedures broken after updates
On Thu, 29 Oct 2009 19:19:28 -0400 Henry Olyer 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
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 wrote:
> On Thu, 29 Oct 2009 20:07:09 + "b. f."
> wrote:
> >On 10/29/09, Scott Bennett wrote:
> >> On Wed, 28 Oct 2009 09:19:08 + "b. f."
> >> wrote:
> >>>On 10/28/09, Scott Bennett 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
Re: lang/gcc43 and lang/gcc44 installation procedures broken after updates
On Thu, 29 Oct 2009 20:07:09 + "b. f."
wrote:
>On 10/29/09, Scott Bennett wrote:
>> On Wed, 28 Oct 2009 09:19:08 + "b. f."
>> wrote:
>>>On 10/28/09, Scott Bennett wrote:
On Tue, 27 Oct 2009 11:28:51 + "b. f."
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/lis
Re: lang/gcc43 and lang/gcc44 installation procedures broken after updates
On 10/29/09, Scott Bennett wrote:
> On Wed, 28 Oct 2009 09:19:08 + "b. f."
> wrote:
>>On 10/28/09, Scott Bennett wrote:
>>> On Tue, 27 Oct 2009 11:28:51 + "b. f."
>>> 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 Wed, 28 Oct 2009 09:19:08 + "b. f."
wrote:
>On 10/28/09, Scott Bennett wrote:
>> On Tue, 27 Oct 2009 11:28:51 + "b. f."
>> 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-b
Re: lang/gcc43 and lang/gcc44 installation procedures broken after updates
On 10/28/09, Scott Bennett wrote:
> On Tue, 27 Oct 2009 11:28:51 + "b. f."
> 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 upda
Re: lang/gcc43 and lang/gcc44 installation procedures broken after updates
On Tue, 27 Oct 2009 11:28:51 + "b. f." 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://
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-po
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.
