2011/11/21 Tilman Keskinöz <ar...@freebsd.org>: > 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
The good news is that our CMake 2.8.6 should already have the integrated automoc functionality. So, is there a patch I can try to replace automoc with the equivalent functionality in cmake for our ports tree ? > > > > * Conrad J. Sabatier [2011-16-21 23:16]: >> On Mon, 21 Nov 2011 17:27:42 +0100 >> Olivier Smedts <oliv...@gid0.org> wrote: >> >>> 2011/11/21 Conrad J. Sabatier <conr...@cox.net>: >>>> On Mon, 21 Nov 2011 07:42:43 -0600 >>>> eculp <ec...@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. >> > > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"