Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 124671 - kwin fails to compile (but not a kwin problem, maybe kde eclasses?)
Summary: kwin fails to compile (but not a kwin problem, maybe kde eclasses?)
Status: RESOLVED CANTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] KDE (show other bugs)
Hardware: All Other
: High normal (vote)
Assignee: Gentoo KDE team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-02 10:44 UTC by Rodolfo Boer
Modified: 2006-08-27 10:13 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rodolfo Boer 2006-03-02 10:44:22 UTC
When I try to upgrade kwin from 3.5.1 to 3.5.1-r1, it bails out on compile due to the following error:

In file included from kcm.cpp:28:
ruleslist.h:23:27: ruleslistbase.h: No such file or directory
In file included from kcm.cpp:28:
ruleslist.h:36: error: expected class-name before '{' token
kcm.cpp: In constructor `KWinInternal::KCMRules::KCMRules(QWidget*, const char*)':
kcm.cpp:47: error: no matching function for call to `QVBoxLayout::addWidget(KWinInternal::KCMRulesList*&)'
/usr/qt/3/include/qlayout.h:386: note: candidates are: void QBoxLayout::addWidget(QWidget*, int, int)
kcm.cpp:48: error: no matching function for call to `KWinInternal::KCMRules::connect(KWinInternal::KCMRulesList*&, const char[17], const char[23])'
/usr/qt/3/include/qobject.h:116: note: candidates are: static bool QObject::connect(const QObject*, const char*, const QObject*, const char*)
/usr/qt/3/include/qobject.h:227: note:                 bool QObject::connect(const QObject*, const char*, const char*) const
make[4]: *** [kcm.lo] Error 1
make[4]: Leaving directory `/usr/tmp/portage/kwin-3.5.1/work/kwin-3.5.1/kwin/kcmkwin/kwinrules'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/usr/tmp/portage/kwin-3.5.1/work/kwin-3.5.1/kwin/kcmkwin'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/tmp/portage/kwin-3.5.1/work/kwin-3.5.1/kwin'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/tmp/portage/kwin-3.5.1/work/kwin-3.5.1'
make: *** [all] Error 2

I searched a bit and the problem is that the generated Makefile is wrong: kdm.cpp should have depended on ruleslistbase.h, going to the build directory and typing "make ruleslistbase.h" works.

Compiling the kdebase source by hand (tar && configure && make) works, the dependency is correct, so I assume the problem is related to the autotools or their use. I'd blame the kde eclasses, because:

1. kwin-3.5.1 fails the same, although I've insalled without problem when it got out

2. I had a similar problem with amarok, built the 1.4 beta, then a couple of days later I reemerged with different use-flags and it failed, so I assumed that the use-flag change was the culprit, but now I recognized the same behaviour (however I did not file a bug since I didn't really need such a change, my intentions were: rebuild, see what changed, get back to the old abits; also I'm lazy!)

I'm using ~x86. Here is my emerge info:

Portage 2.1_pre5-r2 (default-linux/x86/2005.1, gcc-3.4.5, glibc-2.3.6-r3, 2.6.15-gentoo-r5 i686)
=================================================================
System uname: 2.6.15-gentoo-r5 i686 AMD Athlon(tm) XP 2200+
Gentoo Base System version 1.12.0_pre16
ccache version 2.4 [enabled]
dev-lang/python:     2.4.2-r1
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1-r2
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r3
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=athlon-xp -mmmx -m3dnow -msse -mfpmath=sse -fomit-frame-pointer -pipe -O2"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/texmf/web2c /etc/env.d"
CXXFLAGS="-march=athlon-xp -mmmx -m3dnow -msse -mfpmath=sse -fomit-frame-pointer -pipe -O2"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache confcache distlocks sandbox sfperms strict userpriv"
GENTOO_MIRRORS="http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/                 http://gentoo.inode.at/                 http://pandemonium.tiscali.de/pub/gentoo/                 http://gentoo.ngi.it                 http://distfiles.gentoo.org"
LANG="it_IT.UTF-8"
LINGUAS="it en"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/usr/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="x86 3dnow 3dnowext X a52 aac acl acpi alsa apm arts asf avi bash-completion berkdb bitmap-fonts bzip2 crypt css cups dga dlloader doc dts dv dvd dvdr eds emboss encode exif ffmpeg flac foomaticdb gdbm gif gphoto2 gpm gstreamer gtk2 hal imlib jpeg jpeg2k kde kdeenablefinal libg++ libwww logrotate mad matroska mjpeg mmap mmx mmxext mng motif mp3 mpeg musepack ncurses nls nodrm nptl nsplugin offensive ogg oggvorbis opengl pam pam_console pdflib perl png python qt quicktime readline real sdl spell sse ssl subversion tcpd tetex theora tiff truetype truetype-fonts type1-fonts unicode usb vidix vorbis win32codecs wmf xanim xcomposite xml2 xscreensaver xv xvid zlib elibc_glibc kernel_linux linguas_it linguas_en userland_GNU"
Unset:  ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LC_ALL, LDFLAGS, MAKEOPTS
Comment 1 Caleb Tennis (RETIRED) gentoo-dev 2006-03-02 12:08:17 UTC
is ruleslistbase.h generated?

If so, then it's a parallel make error.
Comment 2 Rodolfo Boer 2006-03-02 23:07:21 UTC
(In reply to comment #1)
> is ruleslistbase.h generated?
> 
> If so, then it's a parallel make error.

The file is not generated, and I have not enabled parallel make, so unless it's enabled automatically...
Comment 3 Caleb Tennis (RETIRED) gentoo-dev 2006-03-03 03:45:47 UTC
Sure you do:

make[4]: *** [kcm.lo] Error 1
make[4]: Leaving directory
`/usr/tmp/portage/kwin-3.5.1/work/kwin-3.5.1/kwin/kcmkwin/kwinrules'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/usr/tmp/portage/kwin-3.5.1/work/kwin-3.5.1/kwin/kcmkwin'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/tmp/portage/kwin-3.5.1/work/kwin-3.5.1/kwin'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/tmp/portage/kwin-3.5.1/work/kwin-3.5.1'
make: *** [all] Error 2

You're running 4 makes at the same time...
Comment 4 Rodolfo Boer 2006-03-03 04:33:24 UTC
(In reply to comment #3)
> Sure you do:
[...]

Well, for start, I though that parallel make could be enabled only by setting MAKEOPTS in make.conf, but I have that line commented out, so I don't know where it could be enabled. If there's another way please tell me.

Second, as far as I can remember I've always seen that kind of output from make, I thought it spawns a new process whenever it enters a subdir.

Third, if I go to the build directory (tmp/portage/work/...) and simply type make, which I assume starts a "serial" make, the behaviour and output is just the same.
Comment 5 Rodolfo Boer 2006-03-03 16:09:53 UTC
I'm recompiling amarok and kwin with "ebuild compile" to preserve the partial compilation and making the single files that miss by hand, and they all are generated by uic or (in one case) dcopidl. However other files generated by uic have no problem.

Kwin now is installed, but this does not solve the problem definitely
Comment 6 Caleb Tennis (RETIRED) gentoo-dev 2006-03-03 18:10:23 UTC
probably better to force it off:

MAKEOPTS="" (or try "-j1")

Comment 7 Rodolfo Boer 2006-03-04 03:45:59 UTC
(In reply to comment #6)
> probably better to force it off:
> 
> MAKEOPTS="" (or try "-j1")

I tried both, and the problem is still the same
Comment 8 Rodolfo Boer 2006-03-04 04:00:45 UTC
Ok, I finally found the culprit. I just disabled confcache from features and kwin compiled with no fault
Comment 9 Carsten Lohrke (RETIRED) gentoo-dev 2006-03-04 05:19:49 UTC
Brian, I'm not quite sure to whom to assign this confcache issue now you are retiring. Do you still take care for your pet or does anyone else?
Comment 10 Brian Harring gentoo-dev 2006-03-04 15:09:38 UTC
@caleb: I'm upstream on it, flameeyes has kindly stepped up to maintain ebuild in the tree (eg, he should see these bugs).

Meanwhile... some autotoolings are just horked and won't work with confcache.
RESTRICT="confcache"
Was added to work around this; I'd suggest modifying the ebuild and adding it- it'll just disable confcache for that cpv.
Comment 11 Carsten Lohrke (RETIRED) gentoo-dev 2006-08-27 10:13:59 UTC
Resolving, as confcache is broken, hard masked and therefore unsupported.