From owner-freebsd-questions@FreeBSD.ORG Wed Oct 28 07:10:42 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 866601065676 for ; Wed, 28 Oct 2009 07:10:42 +0000 (UTC) (envelope-from bennett@cs.niu.edu) Received: from mp.cs.niu.edu (mp.cs.niu.edu [131.156.145.41]) by mx1.freebsd.org (Postfix) with ESMTP id 657A68FC15 for ; Wed, 28 Oct 2009 07:10:42 +0000 (UTC) Received: from mp.cs.niu.edu (bennett@localhost [127.0.0.1]) by mp.cs.niu.edu (8.14.3/8.14.3) with ESMTP id n9S7AeGT027660; Wed, 28 Oct 2009 02:10:40 -0500 (CDT) Date: Wed, 28 Oct 2009 02:10:40 -0500 (CDT) From: Scott Bennett Message-Id: <200910280710.n9S7AeZw027659@mp.cs.niu.edu> To: bf1783@googlemail.com Cc: freebsd-questions@freebsd.org Subject: Re: lang/gcc43 and lang/gcc44 installation procedures broken after updates X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 07:10:42 -0000 On Tue, 27 Oct 2009 11:28:51 +0000 "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 * **********************************************************************