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

Olivier Smedts olivier at gid0.org
Mon Nov 21 22:52:31 UTC 2011 

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 ?

>
>
>
> * 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"
>



-- 
Olivier Smedts                                                 _
                                        ASCII ribbon campaign ( )
e-mail: olivier at 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."

More information about the kde-freebsd mailing list