[kde-freebsd] Can't compile kde4 and kdelibs4 with an uptodate amd64 Releng machine. (

H2 h2+lists2011 at fsfe.org
Fri Nov 25 15:23:14 UTC 2011 

On 21.11.2011 23:52, Olivier Smedts wrote:
> 2011/11/21 Tilman Keskinöz<arved at 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 ?

Hi,

is there any news on this? I ccurrently build kdelibs with a shell loop 
that automatically kills automoc every 60seconds and restarts the 
build... very annoying.

Also, packages for kde have now dissappeared from the servers (probably 
due to this), which leaves everyone on amd64 without the possibility of 
installing kde4...

Thank you!
-- 
Best Regards,
Hannes

>>
>>
>>
>> * Conrad J. Sabatier [2011-16-21 23:16]:
>>> On Mon, 21 Nov 2011 17:27:42 +0100
>>> Olivier Smedts<olivier at gid0.org>  wrote:
>>>
>>>> 2011/11/21 Conrad J. Sabatier<conrads at cox.net>:
>>>>> On Mon, 21 Nov 2011 07:42:43 -0600
>>>>> eculp<eculp at 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 at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
>>
>
>
>

More information about the kde-freebsd mailing list