kdebase-3.04-r2 worked fine, though. Have xfree86 4.2.1-r1, xft-2.0-r1, qt-3.1.0-r1. The error follows, and I can provide more information upon request. i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I/usr/include/freetype2 -I/usr/kde/3/include -I/usr/qt/3/include -I/usr/X11R6/include -DQT_THREAD_SUPPORT -D_REENTRANT -DNDEBUG -O2 -march=athlon-tbird -O2 -pipe -c xftgram-kfi.c -fPIC -DPIC -o .libs/xftgram-kfi.o In file included from xftgram.y:29, from xftgram-kfi.c:23: xftint.h:280: conflicting types for `XftDirScan' /usr/X11R6/include/X11/Xft/Xft.h:127: previous declaration of `XftDirScan' xftint.h:392: parse error before '*' token make[4]: *** [xftgram-kfi.lo] Error 1 make[4]: *** Waiting for unfinished jobs.... In file included from xftlex.l:27, from xftlex-kfi.c:23: xftint.h:280: conflicting types for `XftDirScan' /usr/X11R6/include/X11/Xft/Xft.h:127: previous declaration of `XftDirScan' xftint.h:392: parse error before '*' token make[4]: *** [xftlex-kfi.lo] Error 1 make[4]: Leaving directory `/var/tmp/portage/kdebase-3.0.4-r3/work/kdebase-3.0.4/kcontrol/kfontinst/kfontinst' Incidentally, is there a better way to change the email address of a Bugzilla account than throwing the old account away and making a new one?
from which package is your /usr/X11R6/include/X11/Xft/Xft.h? (qpkg -f /usr/X11R6/include/X11/Xft/Xft.h will help, qpkg is from gentoolkit).
xfree-4.2.1-r1
Header of the file is: $XFree86: xc/lib/Xft/Xft.h,v 1.28 2002/08/31 18:08:10 keithp Exp $ md5sum is: dfbedfa6c580bad95961e95cff3aee2e /usr/X11R6/include/X11/Xft/Xft.h (Just to see if I've got a totally weird file... I haven't modified it myself.)
whats the ouput of 'ls /usr/X11R6/include/X11/Xft' ?
XftCompat.h Xft.h
Check your system for existance of Xft.h and XftFreetype.h besides the ones in the X11 dir.
/usr/X11R6/include/X11/Xft/ has both. There was also an extra copy of both (along with a FreeType header) in /root/.Xft/, for an unknown reason. Anyhow, I deleted those and still get the same compilation error, which makes sense given that the path to the header file it wanted to use explicitly referenced the right one. No others, anyhow.
Er, wait, that's wrong. There is no XftFreetype.h anywhere on my system. I overly hastily deleted the directory off of /root, and there is no other.
XftFreetype.h is provided by x11-libs/xft. please 'emerge xft' and 'emerge kdebase'.
sorry, i'm wrong, xftfreetype.h should bot be on your system (it is only from xft-1.x).
So would that make the problem xft-2.0 moving the entire directory rather than just the files it replaces? (Now that I just re-emerged xft, I see that it is responsible for that directory off of my root.)
Err, no, that makes no sense as this problem isn't related to XftFreetype.h anyway. I'm not thinking very well today.
The problem is pretty much exactly what the error says (Fancy that!)... In line 280 of kdebase-3.0.4/kcontrol/kfontinst/kfontinst/xftint.h there's a: Bool XftDirScan (XftFontSet *set, const char *dir); This conflicts with a similar, yet different line in Xft.h, namely: FcBool XftDirScan (FcFontSet *set, const char *dir, FcBool force); I don't *think* my installation of 3.0.4-r2 predates my move to xft-2.0 and GNOME 2.1, but it could be a nice little conflict between the two.
yes, this is exactly the problem. when did you merge kdelibs? before or after having a qt with xft-2? it may be that emerge kdelibs solves this problem.
Well, the /root/.Xft was a little hack i made which would make reverting to xft1 easier if you ran into trouble, so that doesn't matter. It's just possible that kde used the same name for a function, which wouldn't get noticed if he had installed that package before he installed xft2. I didn't know where to look for the double declaration, since i don't have KDE at all :)
I distantly remember reading something about this in a message either on Slashdot or some KDE news website which garnered a reply saying 'we know, and have fixed it in 3.1'. Lo and behold, kdebase-3.1-rc3 does install fine. Maybe the easiest fix is to just make the kdebase-3.0.x ebuilds be blocked by xft-2.0? Is it possible to put out a message saying 'it's okay to reinstall xft-2.0 again afterward' on that, or must that be left to the user to figure out by way of the block not being symmetric?
I have the exact same problem when trying to build (complains about: In file included from Config.cpp:45: xftint.h:280: declaration of C function `int XftDirScan(XftFontSet*, const char*)' conflicts with /usr/X11R6/include/X11/Xft/Xft.h:127: previous declaration `FcBool XftDirScan(FcFontSet*, const char*, int)' here What's the fix? Re-emerge xft and then rebuild kdebase? I have xft-2.0-r1. or go to kdebase-3.1_rc3.ebuild? Thanks,
emerging kdebase-3.1_rc3 should work. to track this bug down, i need to know what you did. did you: emerge qt-3.1 emerge xft emerge kdebase or did you emerge xft emerge qt emerge kdebase? the second way should work (i tested this ~3 times here), the first way can be broken (not tested yet).
Hard to remember which way I did my emerges. Is there a way to tell by looking at file timestamps somewhere (somewhat of an audit trail)? Is the file /var/db/pkg/x11-libs/qt-3.1.0-r1/COUNTER a good indicator of when a package was built? Looking at that and /var/db/pkg/x11-libs/xft-2.0-r1/COUNTER I would say my route was emerge xft emerge qt emerge kdebase
take a look at /var/log/emerge.log
egrep '(qt-3.1.0-r1|xft-2.0-r1)' /var/log/emerge.log 1037716553: *** emerge /usr/portage/x11-libs/xft/xft-2.0-r1.ebuild 1037716554: >>> emerge (1 of 1) x11-libs/xft-2.0-r1 to / 1037716590: ::: completed emerge (1 of 1) x11-libs/xft-2.0-r1 to / 1038237621: >>> emerge (10 of 12) x11-libs/qt-3.1.0-r1 to / 1038237621: ::: completed emerge (10 of 12) x11-libs/qt-3.1.0-r1 to / 1038238484: >>> emerge (1 of 1) x11-libs/qt-3.1.0-r1 to / 1038242389: ::: completed emerge (1 of 1) x11-libs/qt-3.1.0-r1 to / which means xft first, and then qt twice...
Your second way (xft-2.0 qt-3.1, kdebase-3.0.x) does not work. No matter how it gets built, the xfree includes as well as that one file in kdebase are going to conflict.
I'm not getting anywhere with this. In comment 18, you said way#1 is prone to be broken and way #2 should be followed. According to my /var/log/emerge.log, I did follow way #2 and still a broken kdebase emerge in the end.
well, way#2 works here. against which libXft is /usr/kde/3/lib/libkdecore.so linked?
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x45736000)
Just did: emerge /usr/portage/x11-libs/xft/xft-2.0-r1.ebuild qt kdebase with the same result, broken kdebase ebuild in the end. Any more ideas?
something more for you to look at: root # ls -al /usr/X11R6/lib/libXft.so lrwxrwxrwx 1 root root 23 Dec 5 09:58 /usr/X11R6/lib/libXft.so -> ../../lib/libXft.so.2.0 root # ldd /usr/X11R6/lib/libXft.so libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x40027000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x4002e000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x40072000) libc.so.6 => /lib/libc.so.6 (0x40093000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x401be000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x401ce000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0x402b1000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) libdl.so.2 => /lib/libdl.so.2 (0x402d7000)
I have a different problem comiling kdebase-3.0.4-r3: i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/kde/3/include -I/usr/qt/3/include -I/usr/X11R6/include -DQT_THREAD_SUPPORT -D_REENTRANT -DNDEBUG -DNO_DEBUG -O2 -O3 -fomit-frame-pointer -pipe -march=athlon -mmmx -m3dnow -ffast-math -fno-strength-reduce -fno-exceptions -fno-check-new -DQT_CLEAN_NAMESPACE -DQT_NO_COMPAT -DQT_NO_ASCII_CAST -c -o keyecandypagedlg.o `test -f keyecandypagedlg.cpp || echo './'`keyecandypagedlg.cpp keyecandypagedlg.cpp: In constructor `KEyeCandyPageDlg::KEyeCandyPageDlg(QWidget*, const char*, unsigned int)': keyecandypagedlg.cpp:86: invalid use of undefined type `struct KListView' keyecandypagedlg.h:18: forward declaration of `struct KListView' keyecandypagedlg.cpp:88: no matching function for call to `QGridLayout::addWidget(KListView*&, int, int)' /usr/qt/3/include/qlayout.h:323: candidates are: void QGridLayout::addWidget(QWidget*, int, int, int = 0) QT is version 3.1.0-r1
Corporate Gadfly: please try emerge kdelibs kdebase Uwe: which version of kdelibs is merged? please also post your gcc/glibc.
kdelibs-3.0.4-r1 gcc-3.2-r4 glibc-2.2.5-r7 Anything else of interest? I will try to reemerge kdelibs. I updated qt AFTER updating kdelibs.
Hannes, is it possible that you've remerged xfree since you installed xft-2.0? I noticed today that the new revision of xfree blew away the xft-2.0 header files, which would then result in the conflicting declarations between xft-2.0 and kdebase-3.0.x disappearing.
Reemerging kdelibs solved my problem from comment #28.
Uwe: great :) no, i didn't reemerge xfree after emerge xft.
Hannes: Just tried your suggestion from comment #29, by doing emerge /usr/portage/kde-base/kdelibs/kdelibs-3.0.4-r1.ebuild /usr/portage/kde-base/kdebase/kdebase-3.0.4-r3.ebuild and ended up with a broken ebuild for kdebase with the same error. My xfree version is xfree-4.2.1-r1. Do you think going to xfree-4.2.1-r2 might help?
i don't know if xfree-4.2.1-r2 will help, but i think it will not. kde-3.1_rc5 is out, this resolves this issue afaics.
Wouldn't you know it? Over the weekend, I left the machine running with an upgrade to >>> emerge (1 of 2) x11-base/xfree-4.2.1-r2 to / followed by: >>> emerge (2 of 2) kde-base/kdebase-3.0.4-r3 to / I was surprised to come in this morning to see kdebase with a successful build. Can someone else who was having problems try this? synonymousca@yahoo.com?
Yeah, that was going to work fine all along... Xfree-4.2.1 replaces the xft-2.0 Xft.h file with its own Xft-1 headers. Now your apps which depend on Xft-2.0 will fail to build (until you remerge xft). This should be dealt with in the ebuilds somehow, possibly with an Xft-1.0 ebuild which can be set as a dependency of anything that requires it and which will then automatically be upgraded back to xft-2.0 the next time someone does an `emerge -u world`. On the other hand, when kde-3.1 final comes out, this'll be a moot point given that, so far as I know, only pango and kdebase-3.0.x have xft-related issues. Pango's will be gone if we always have xft-2 and always use pango-1.1.x.
Yep, its basically Xft2.0 headers that causes things to break. This is fixed in kdebase-3.05a-r1, so please update to that. *** This bug has been marked as a duplicate of 9423 ***
