Date: Mon, 21 Nov 2011 15:38:28 -0600 From: "Conrad J. Sabatier" <conrads@cox.net> To: freebsd-ports@freebsd.org Cc: Olivier Smedts <olivier@gid0.org> Subject: Re: Can't compile kde4 and kdelibs4 with an uptodate amd64 Releng machine. ( Message-ID: <20111121153828.4e04a92a@cox.net> In-Reply-To: <CABzXLYNF6T-GzOVL9OBjPKfOfb9xjkN4_ffa=V=rZma4OdBVHQ@mail.gmail.com> References: <20111121074243.18902mpt8znqto40@econet.encontacto.net> <20111121100945.2c888eaf@cox.net> <CABzXLYNF6T-GzOVL9OBjPKfOfb9xjkN4_ffa=V=rZma4OdBVHQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
> >>
> >> Generating kurlnavigator.moc
> >> Generating moc_kdiroperatordetailview_p.cpp
> >> [ =A01%] Built target kfile_automoc
> >> Scanning dependencies of target kdeinit_kconf_update_automoc
> >> Scanning dependencies of target docbookl10nhelper_automoc
> >> [ =A01%] Built target kdeinit_kconf_update_automoc
> >> [ =A01%] Built target docbookl10nhelper_automoc
> >> Scanning dependencies of target genshortcutents_automoc
> >> Scanning dependencies of target kio_ghelp_automoc
> >> [ =A01%] Built target genshortcutents_automoc
> >> [ =A01%] Built target kio_ghelp_automoc
> >> Scanning dependencies of target kio_help_automoc
> >> Scanning dependencies of target meinproc4_automoc
> >> [ =A01%] Built target kio_help_automoc
> >> [ =A01%] Built target meinproc4_automoc
> >> Scanning dependencies of target meinproc4_simple_automoc
> >> Scanning dependencies of target kio_file_automoc
> >> [ =A01%] Built target meinproc4_simple_automoc
>=20
> I've got this behavior on the 2 desktop machines I use.
>=20
> >> kdepimlibs4 stops here:
> >>
> >> Scanning dependencies of target kimg_pcx_automoc
> >> Scanning dependencies of target kimg_pic_automoc
> >> [ =A01%] Built target kimg_pcx_automoc
> >> [ =A01%] Built target kimg_pic_automoc
> >> Scanning dependencies of target kimg_psd_automoc
> >> Scanning dependencies of target kimg_ras_automoc
> >> [ =A01%] Built target kimg_psd_automoc
> >> [ =A01%] Built target kimg_ras_automoc
> >> Scanning dependencies of target kimg_rgb_automoc
> >> Scanning dependencies of target kimg_tga_automoc
> >> [ =A01%] Built target kimg_rgb_automoc
> >> [ =A01%] Built target kimg_tga_automoc
> >> Scanning dependencies of target kimg_xcf_automoc
> >> Scanning dependencies of target kimg_xview_automoc
> >> [ =A01%] Built target kimg_xview_automoc
> >> [ =A01%] Built target kimg_xcf_automoc
> >> Scanning dependencies of target kdnssd_automoc
> >> Scanning dependencies of target krosscore_automoc
> >> Generating interpreter.moc
> >> Generating script.moc
> >> Generating action.moc
> >> Generating actioncollection.moc
> >> Generating manager.moc
> >> [ =A01%] Built target krosscore_automoc
> >
> > So where are the errors? =A0There are none in the output you posted.
>=20
> I think there's no error (if it's the same problem as mine).
>=20
> 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 :
>=20
> # 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.
>=20
> 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.
>=20
> 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=3Dyes
> SVN=3D/usr/local/bin/svn
> CPUTYPE?=3Dcore2
I've been using the (undocumented, at least in /etc/make.conf)
CPUTYPE?=3Dnative 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=3DCORE
> CFLAGS=3D-O2 -pipe -march=3Dcore2 -fomit-frame-pointer
There's no need to add -march=3D to CFLAGS, if you're setting CPUTYPE
(that's what CPUTYPE is for).
> NO_CPU_CFLAGS=3Dyes
Why are you setting CPUTYPE, and then telling make not to use it? And
then, setting the CPU type anyway in your CFLAGS? :-)
> COPTFLAGS=3D-O2 -pipe -march=3Dcorei7 -fomit-frame-pointer
> NO_CPU_COPTFLAGS=3Dyes
Again, same question as above.
Even more pointedly, why core2 in CFLAGS and corei7 (what is that?) in
COPTFLAGS?
> BOOTWAIT=3D0
> WITHOUT_PROFILE=3Dyes
Yes, WITHOUT_PROFILE=3Dyes 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} =3D=3D "cc"
> CC=3Dclang
> .endif
> .if !defined(CXX) || ${CXX} =3D=3D "c++"
> CXX=3Dclang++
> .endif
> .if !defined(CPP) || ${CPP} =3D=3D "cpp"
> CPP=3Dclang -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=3D
> WERROR=3D
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=3D -Wno-error
WERROR=3D -Wno-error
> .endif
>=20
> EXPLICIT_PACKAGE_DEPENDS=3Dyes
> FORCE_MAKE_JOBS=3Dyes
Have you tried unsetting this last variable to see if it stops these
"freezes" from occurring?
> WRKDIRPREFIX=3D/tmp
Do you have any particular reason for not using the default for this
variable?
> WITHOUT_X11R6_SYMLINK=3Dyes
> NOPORTDOCS=3Dyes
> NOPORTEXAMPLES=3Dyes
> WITH_OPTIMIZED_CFLAGS=3Dyes
> VIDEO_DRIVER=3Dati
> WITHOUT_NOUVEAU=3Dyes
> WITHOUT_HAL=3Dyes
> WITHOUT_DBUS=3Dyes
> WITHOUT_GCONF=3Dyes
> WITHOUT_LIBNOTIFY=3Dyes
> WITHOUT_AVAHI=3Dyes
> WITH_CDROM=3D/dev/cd0
> WITHOUT_SWITCHER=3Dyes
> THUNDERBIRD_I18N=3Dfr
> LOCALIZED_LANG=3Dfr
> PERL_VERSION=3D5.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.
--=20
Conrad J. Sabatier
conrads@cox.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111121153828.4e04a92a>