[ 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.
