Date: Wed, 28 Oct 2009 02:10:40 -0500 (CDT) From: Scott Bennett <bennett@cs.niu.edu> To: bf1783@googlemail.com Cc: freebsd-questions@freebsd.org Subject: Re: lang/gcc43 and lang/gcc44 installation procedures broken after updates Message-ID: <200910280710.n9S7AeZw027659@mp.cs.niu.edu>
next in thread | raw e-mail | index | archive | help
On Tue, 27 Oct 2009 11:28:51 +0000 "b. f." <bf1783@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 *
**********************************************************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200910280710.n9S7AeZw027659>