Date: Mon, 21 Nov 2011 23:21:00 +0100 From: =?ISO-8859-1?Q?Tilman_Keskin=F6z?= <arved@FreeBSD.org> To: freebsd-ports@freebsd.org Subject: Re: Can't compile kde4 and kdelibs4 with an uptodate amd64 Releng machine. ( Message-ID: <4ECACECC.7070503@FreeBSD.org> In-Reply-To: <20111121153828.4e04a92a@cox.net> References: <20111121074243.18902mpt8znqto40@econet.encontacto.net> <20111121100945.2c888eaf@cox.net> <CABzXLYNF6T-GzOVL9OBjPKfOfb9xjkN4_ffa=V=rZma4OdBVHQ@mail.gmail.com> <20111121153828.4e04a92a@cox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
There has been a thread on the cvs-ports Mailinglist about this with the subject "cvs commit: ports/Mk bsd.cmake.mk" and there is a bugreport https://bugs.kde.org/show_bug.cgi?id=276461 * Conrad J. Sabatier [2011-16-21 23:16]: > On Mon, 21 Nov 2011 17:27:42 +0100 > Olivier Smedts <olivier@gid0.org> wrote: > >> 2011/11/21 Conrad J. Sabatier <conrads@cox.net>: >>> On Mon, 21 Nov 2011 07:42:43 -0600 >>> eculp <eculp@encontacto.net> 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: >>>> >>>> [ 1%] Built target krosscore_automoc >>> >>> So where are the errors? There are none in the output you posted. >> >> I think there's no error (if it's the same problem as mine). >> >> 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 : >> >> # 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 -<some number of lines> | 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. >> >> 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. >> >> 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=yes >> SVN=/usr/local/bin/svn >> CPUTYPE?=core2 > > I've been using the (undocumented, at least in /etc/make.conf) > CPUTYPE?=native 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=CORE >> CFLAGS=-O2 -pipe -march=core2 -fomit-frame-pointer > > There's no need to add -march= to CFLAGS, if you're setting CPUTYPE > (that's what CPUTYPE is for). > >> NO_CPU_CFLAGS=yes > > Why are you setting CPUTYPE, and then telling make not to use it? And > then, setting the CPU type anyway in your CFLAGS? :-) > >> COPTFLAGS=-O2 -pipe -march=corei7 -fomit-frame-pointer >> NO_CPU_COPTFLAGS=yes > > Again, same question as above. > > Even more pointedly, why core2 in CFLAGS and corei7 (what is that?) in > COPTFLAGS? > >> BOOTWAIT=0 >> WITHOUT_PROFILE=yes > > Yes, WITHOUT_PROFILE=yes 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} == "cc" >> CC=clang >> .endif >> .if !defined(CXX) || ${CXX} == "c++" >> CXX=clang++ >> .endif >> .if !defined(CPP) || ${CPP} == "cpp" >> CPP=clang -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= >> WERROR= > > 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= -Wno-error > WERROR= -Wno-error > >> .endif >> >> EXPLICIT_PACKAGE_DEPENDS=yes >> FORCE_MAKE_JOBS=yes > > Have you tried unsetting this last variable to see if it stops these > "freezes" from occurring? > >> WRKDIRPREFIX=/tmp > > Do you have any particular reason for not using the default for this > variable? > >> WITHOUT_X11R6_SYMLINK=yes >> NOPORTDOCS=yes >> NOPORTEXAMPLES=yes >> WITH_OPTIMIZED_CFLAGS=yes >> VIDEO_DRIVER=ati >> WITHOUT_NOUVEAU=yes >> WITHOUT_HAL=yes >> WITHOUT_DBUS=yes >> WITHOUT_GCONF=yes >> WITHOUT_LIBNOTIFY=yes >> WITHOUT_AVAHI=yes >> WITH_CDROM=/dev/cd0 >> WITHOUT_SWITCHER=yes >> THUNDERBIRD_I18N=fr >> LOCALIZED_LANG=fr >> PERL_VERSION=5.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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4ECACECC.7070503>