From owner-freebsd-ports@FreeBSD.ORG Mon Nov 21 21:38:40 2011 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E93B1106564A for ; Mon, 21 Nov 2011 21:38:40 +0000 (UTC) (envelope-from conrads@cox.net) Received: from eastrmfepo201.cox.net (eastrmfepo201.cox.net [68.230.241.216]) by mx1.freebsd.org (Postfix) with ESMTP id 897288FC0A for ; Mon, 21 Nov 2011 21:38:40 +0000 (UTC) Received: from eastrmimpo306.cox.net ([68.230.241.238]) by eastrmfepo201.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20111121213834.JNTC4752.eastrmfepo201.cox.net@eastrmimpo306.cox.net>; Mon, 21 Nov 2011 16:38:34 -0500 Received: from serene.no-ip.org ([98.164.86.236]) by eastrmimpo306.cox.net with bizsmtp id zxeZ1h00d55wwzE02xeavu; Mon, 21 Nov 2011 16:38:34 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020202.4ECAC4DA.00EC,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=1.1 cv=cdJjHAINPiZBdT+VAeFfLOvj93neuvwrRIGsWSZO+Cw= c=1 sm=1 a=MZZWkA004osA:10 a=G8Uczd0VNMoA:10 a=8nJEP1OIZ-IA:10 a=uAbGmPAyUfLL1M3oYAsfuA==:17 a=TfWq9i5PAAAA:8 a=kviXuzpPAAAA:8 a=bh5JU0MlAAAA:8 a=mLdtMvTGxGcuuyEkkHUA:9 a=RUC4PUSny2c63nrr4G0A:7 a=wPNLvfGTeEIA:10 a=Vce-_cLKp2kA:10 a=4vB-4DCPJfMA:10 a=zX0te6EY65cA:10 a=QhgMCs7cPERQSQKc:21 a=bEtXZKOQJEyExiQq:21 a=uAbGmPAyUfLL1M3oYAsfuA==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Received: from cox.net (localhost [127.0.0.1]) by serene.no-ip.org (8.14.5/8.14.5) with ESMTP id pALLcXfw010048; Mon, 21 Nov 2011 15:38:33 -0600 (CST) (envelope-from conrads@cox.net) Date: Mon, 21 Nov 2011 15:38:28 -0600 From: "Conrad J. Sabatier" To: freebsd-ports@freebsd.org Message-ID: <20111121153828.4e04a92a@cox.net> In-Reply-To: References: <20111121074243.18902mpt8znqto40@econet.encontacto.net> <20111121100945.2c888eaf@cox.net> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Olivier Smedts Subject: Re: Can't compile kde4 and kdelibs4 with an uptodate amd64 Releng machine. ( X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 21:38:41 -0000 On Mon, 21 Nov 2011 17:27:42 +0100 Olivier Smedts wrote: > 2011/11/21 Conrad J. Sabatier : > > On Mon, 21 Nov 2011 07:42:43 -0600 > > eculp wrote: > >> > >> I have tried building both from the different ports and even more > >> using portmaster and all stop ate similar locations in kdelabs4. > >> Maybe there is something that I should or could build first. > >> > >> errors follow: > >> > >> kdelibs stops here: > >> > >> Generating kurlnavigator.moc > >> Generating moc_kdiroperatordetailview_p.cpp > >> [ =A01%] Built target kfile_automoc > >> Scanning dependencies of target kdeinit_kconf_update_automoc > >> Scanning dependencies of target docbookl10nhelper_automoc > >> [ =A01%] Built target kdeinit_kconf_update_automoc > >> [ =A01%] Built target docbookl10nhelper_automoc > >> Scanning dependencies of target genshortcutents_automoc > >> Scanning dependencies of target kio_ghelp_automoc > >> [ =A01%] Built target genshortcutents_automoc > >> [ =A01%] Built target kio_ghelp_automoc > >> Scanning dependencies of target kio_help_automoc > >> Scanning dependencies of target meinproc4_automoc > >> [ =A01%] Built target kio_help_automoc > >> [ =A01%] Built target meinproc4_automoc > >> Scanning dependencies of target meinproc4_simple_automoc > >> Scanning dependencies of target kio_file_automoc > >> [ =A01%] Built target meinproc4_simple_automoc >=20 > I've got this behavior on the 2 desktop machines I use. >=20 > >> kdepimlibs4 stops here: > >> > >> Scanning dependencies of target kimg_pcx_automoc > >> Scanning dependencies of target kimg_pic_automoc > >> [ =A01%] Built target kimg_pcx_automoc > >> [ =A01%] Built target kimg_pic_automoc > >> Scanning dependencies of target kimg_psd_automoc > >> Scanning dependencies of target kimg_ras_automoc > >> [ =A01%] Built target kimg_psd_automoc > >> [ =A01%] Built target kimg_ras_automoc > >> Scanning dependencies of target kimg_rgb_automoc > >> Scanning dependencies of target kimg_tga_automoc > >> [ =A01%] Built target kimg_rgb_automoc > >> [ =A01%] Built target kimg_tga_automoc > >> Scanning dependencies of target kimg_xcf_automoc > >> Scanning dependencies of target kimg_xview_automoc > >> [ =A01%] Built target kimg_xview_automoc > >> [ =A01%] Built target kimg_xcf_automoc > >> Scanning dependencies of target kdnssd_automoc > >> Scanning dependencies of target krosscore_automoc > >> Generating interpreter.moc > >> Generating script.moc > >> Generating action.moc > >> Generating actioncollection.moc > >> Generating manager.moc > >> [ =A01%] Built target krosscore_automoc > > > > So where are the errors? =A0There are none in the output you posted. >=20 > I think there's no error (if it's the same problem as mine). >=20 > For me, the build process seems to stop/freeze randomly, most often > after "Built target XXX". It affects only KDE ports, no other > qt4-qmake or cmake consumer. No CPU usage. No disk usage. No excessive > or changing memory usage... I didn't report it earlier because I don't > know how to debug this, and it did not seem to affect other users > (until now). OK, I didn't get that point from the original poster. I was looking to see some actual error output. > Here is the "workaround" I painfully used on my 2 desktop machines : >=20 > # cd /usr/ports/x11/kde4 > # make > wait for a freeze... > ^C > # make > wait for a freeze... > ^C > # make > ... > I maybe had to restart the build one or two hundred times to have a > fully installed KDE4. Wow, "painful" is an understatement here, to say the least. :-) Have you tried using truss or ktrace to see what's going on when these "freezes" occur? You'll want to be sure to enable tracing descendents of the original make process as well. Ports makes, as you no doubt are aware, spawn numerous processes along the way. truss -f make (or) ktrace -i make See the man pages for other options you may want to use as well. ktrace, in particular, will produce *copious* output. You'll probably want to just do a "tail" on the generated ktrace.out file: kdump | tail - | more > I've got this behavior since KDE 4.7.X (4.7.2 and 4.7.3), I had no > problems building KDE 4.6.X. >=20 > I even tried deleting all ports, cleaning /usr/local, tried again. No > change. Tried compiling all ports with gcc instead of clang, no > change. Forced make jobs UNSAFE, no change. >=20 > I use FreeBSD 9.0 amd64, system built with clang (are you ?). No, I only use the default system gcc: # gcc -v Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070831 patched [FreeBSD] > %cat /etc/make.conf > SVN_UPDATE=3Dyes > SVN=3D/usr/local/bin/svn > CPUTYPE?=3Dcore2 I've been using the (undocumented, at least in /etc/make.conf) CPUTYPE?=3Dnative with no problems for quite some time now. Let gcc detect the processor type and generate the appropriate code. Eliminates any guesswork in trying to select the correct setting for CPUTYPE. > KERNCONF=3DCORE > CFLAGS=3D-O2 -pipe -march=3Dcore2 -fomit-frame-pointer There's no need to add -march=3D to CFLAGS, if you're setting CPUTYPE (that's what CPUTYPE is for). > NO_CPU_CFLAGS=3Dyes Why are you setting CPUTYPE, and then telling make not to use it? And then, setting the CPU type anyway in your CFLAGS? :-) > COPTFLAGS=3D-O2 -pipe -march=3Dcorei7 -fomit-frame-pointer > NO_CPU_COPTFLAGS=3Dyes Again, same question as above. Even more pointedly, why core2 in CFLAGS and corei7 (what is that?) in COPTFLAGS? > BOOTWAIT=3D0 > WITHOUT_PROFILE=3Dyes Yes, WITHOUT_PROFILE=3Dyes is the most sensible choice for most users. Should be enabled by default, IMHO. > .if !${.CURDIR:M/usr/ports/deskutils/kdepimlibs4*} && > !${.CURDIR:M/usr/ports/devel/icu*} && > !${.CURDIR:M/usr/ports/editors/kate*} && > !${.CURDIR:M/usr/ports/games/kdegames4*} && > !${.CURDIR:M/usr/ports/graphics/libwpg*} && > !${.CURDIR:M/usr/ports/graphics/netpbm*} && > !${.CURDIR:M/usr/ports/graphics/vigra*} && > !${.CURDIR:M/usr/ports/multimedia/kdemultimedia4*} && > !${.CURDIR:M/usr/ports/net/hupnp*} && > !${.CURDIR:M/usr/ports/net/kdenetwork4*} && > !${.CURDIR:M/usr/ports/textproc/libwpd*} && > !${.CURDIR:M/usr/ports/textproc/libwps*} && > !${.CURDIR:M/usr/ports/www/firefox*} && > !${.CURDIR:M/usr/ports/www/libxul*} && > !${.CURDIR:M/usr/ports/www/qt4-webkit*} && > !${.CURDIR:M/usr/ports/x11/kde4-baseapps*} && > !${.CURDIR:M/usr/ports/x11/kde4-runtime*} && > !${.CURDIR:M/usr/ports/x11/kde4-workspace*} && > !${.CURDIR:M/usr/ports/x11/kdelibs4*} > .if !defined(CC) || ${CC} =3D=3D "cc" > CC=3Dclang > .endif > .if !defined(CXX) || ${CXX} =3D=3D "c++" > CXX=3Dclang++ > .endif > .if !defined(CPP) || ${CPP} =3D=3D "cpp" > CPP=3Dclang -E > .endif Hmmm. Could it be that your problem is related to your selective use of clang instead of gcc for certain ports (combined with using clang for the base system/kernel)? > NO_WERROR=3D > WERROR=3D What is your intention in unsetting these last two variables? If the idea is to ensure that warnings will never cause an error to be generated, you probably want to set both instead to: NO_WERROR=3D -Wno-error WERROR=3D -Wno-error > .endif >=20 > EXPLICIT_PACKAGE_DEPENDS=3Dyes > FORCE_MAKE_JOBS=3Dyes Have you tried unsetting this last variable to see if it stops these "freezes" from occurring? > WRKDIRPREFIX=3D/tmp Do you have any particular reason for not using the default for this variable? > WITHOUT_X11R6_SYMLINK=3Dyes > NOPORTDOCS=3Dyes > NOPORTEXAMPLES=3Dyes > WITH_OPTIMIZED_CFLAGS=3Dyes > VIDEO_DRIVER=3Dati > WITHOUT_NOUVEAU=3Dyes > WITHOUT_HAL=3Dyes > WITHOUT_DBUS=3Dyes > WITHOUT_GCONF=3Dyes > WITHOUT_LIBNOTIFY=3Dyes > WITHOUT_AVAHI=3Dyes > WITH_CDROM=3D/dev/cd0 > WITHOUT_SWITCHER=3Dyes > THUNDERBIRD_I18N=3Dfr > LOCALIZED_LANG=3Dfr > PERL_VERSION=3D5.10.1 While setting all of these variables globally like this is most likely perfectly harmless, there *is* nonetheless a possibility of some unexpected side-effect that's going unnoticed in some of your ports builds. (locale stuff snipped) Sorry I don't have any more useful help to provide. Try tracing these "freezing" builds and see if anything "interesting" turns up. --=20 Conrad J. Sabatier conrads@cox.net