from config.log: configure:24093: checking if UIC has KDE plugins available configure:24120: /usr/qt/3/bin/uic -L /usr/kde/3.3/lib/kde3/plugins/designer -nounload -impl actest.h actest.ui > actest.cpp configure:24123: $? = 0 configure:24134: result: no configure:24137: error: you need to install kdelibs first. Inspecting aclocal.m4, I find that it's using the following test: cat > actest.ui << EOF <!DOCTYPE UI><UI version="3.0" stdsetdef="1"> <class>NewConnectionDialog</class> <widget class="QDialog"> <widget class="KLineEdit"> <property name="name"> <cstring>testInput</cstring> </property> </widget> </widget> </UI> EOF /usr/qt/3/bin/uic -L /usr/kde/3.3/lib/kde3/plugins/designer -nounload -impl actest.h actest.ui > actest.cpp grep klineedit actest.cpp Since the generated actest.cpp doesn't include "klineedit" (in all lowercase), configure claims that kde-libs needs to be merged. However, if I simply force the test to succeed (by putting kde_cv_uic_plugins=yes in my environment), kdiff3 builds correctly. Reproducible: Always Steps to Reproduce: 1.emerge kdiff3 Portage 2.0.51-r15 (default-linux/x86/2004.3, gcc-3.3.5, glibc-2.3.4.20040808-r1, 2.6.10-co-0.6.2-pre7 i686) ================================================================= System uname: 2.6.10-co-0.6.2-pre7 i686 AMD Athlon(tm) 64 Processor 2800+ Gentoo Base System version 1.4.16 Python: dev-lang/python-2.2.3-r1,dev-lang/python-2.3.4 [2.3.4 (#1, Jan 8 2005, 13:49:38)] distcc 2.16 i586-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]dev-lang/python: 2.2.3-r1, 2.3.4 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.6.3, 1.9.4, 1.4_p6, 1.5, 1.8.5-r3, 1.7.9-r1 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -mmmx -mfpmath=sse -msse -msse2 -m3dnow -O3 -pipe" CHOST="i586-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -mmmx -mfpmath=sse -msse -msse2 -m3dnow -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow X Xaw3d acl apache2 arts audiofile bash-completion berkdb bitmap-fonts bonobo bzip2 crypt cups curl emacs esd f77 fam firebird flac font-server fortran gdbm gif gnome gnutls gstreamer gtk gtk2 gtkhtml guile imagemagick imlib ipv6 java javascript jpeg junit kde kerberos libclamav libg++ libwww mad maildir mikmod mmx mozilla mozsvg mpeg ncurses nptl nptlonly offensive oggvorbis opengl pam pcre pdflib perl pic png postgres python qt readline ruby samba sdl slang speex spell sqlite ssl tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts wxwindows xml xml2 xmms xprint xv zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS
Did you recently upgrade Qt? Do you have another version of Qt lying around on disk somewhere? Most likely if you re-emerge kdelibs you'll be fine.
No recent upgrade to Qt. No alternate version of Qt on-disk. Further, it's obvious that the test is broken -- if it weren't, the build wouldn't work perfectly when the system is forced to ignore it. The generated actest.cpp looks perfectly acceptable -- it just happens not to include the string "klineedit". Even so, I've remerged kdelibs, and kdiff3 now compiles without incident.
The problem is that it can't load the .so file it links. The wording is pretty bad for this bug, though. Not much I can do. I wrote a FAQ entry about this topic on the KDE website, and I've addressed it many times, and asked about getting fixes on the mailing list, but there's no good check and it seems nobody wants to fix it upstream.
I really think that the test is right. The explanation is in the "Build Key": http://doc.trolltech.com/3.3/plugins-howto.html The same problem happens with the style as also they are QT plugins.
*** Bug 82070 has been marked as a duplicate of this bug. ***
*** Bug 81511 has been marked as a duplicate of this bug. ***
I think that we should probably add in the ebuild a warning about this problem. A more advanced feature will be a check that will look which files => ebuilds should be recompiled and inform the user to do this. Dunno if this is easy and possible to do.
*** Bug 82732 has been marked as a duplicate of this bug. ***
Does anyone know the affected ebuilds, I'd like to mask them here, Thanks.
Is there a known workaround for this problem?
remerge kdelibs
remerging kdelibs worked for me
*** Bug 83326 has been marked as a duplicate of this bug. ***
*** Bug 83397 has been marked as a duplicate of this bug. ***
*** Bug 83405 has been marked as a duplicate of this bug. ***
*** Bug 83460 has been marked as a duplicate of this bug. ***
*** Bug 87523 has been marked as a duplicate of this bug. ***
*** Bug 94806 has been marked as a duplicate of this bug. ***
I can't get this to work, including the workaround. I'm on amd64, and I have the binary 32bit version of qt installed - but I removed that, remerged qt, kdelibs, and it still doensn't work...
(In reply to comment #19) > I can't get this to work, including the workaround. Then this is probably a different problem, and we need more informations. In qt-3.3.4-r7 I added a warning as suggested in comment #7. Unfortunately this is the best we can do in this situation.
Hi, My bug was recently marked as a duplicate of this, so I'll give a little explanation of what it was and what seemed to fix it, and hopefully this may give some insight into fixing it. I have an AMD64, but everything is compiled in 32-bit mode and I haven't touched anything 64-bit. I am however running a hardened copy of gcc. When I compile qt and polymer (a style plugin for qt), they both compile fine without any errors but the polymer plugin doesn't show up in the style list. I also compiled another test plugin that I was provided in my bug, and that also didn't show up. I recently recompiled polymer using the vanilla-gcc config (ie without the hardened pic/pie flags) and qtconfig then had it in the list, and the plugin worked fine. I've also found similar module loading problems with the gstreamer framework, which currently won't work with position independent code. So, is this the same bug? Will it be fixed upstream? Should qt plugins work in a hardened environment? If anyone needs any more details, or has tests for me to run to try and narrow down the problem, I'll be very happy to do whatever, just let me know. Thanks, Mike 5:)
In general this bug is about the fact that the Qt plugin loader is very strict and can refuse to load plugins for various reasons (mainly explained here: http://doc.trolltech.com/3.3/plugins-howto.html) It is not fully clear whether the hardened gcc problem is explained by the above reference (maybe it's just the fact that Qt and the plugin were compiled with different versions of gcc?), if someone is interested and has the time and skill, he can create testcase plugins (there are examples in the Qt docs) and try to manually compile them in a controlled environment...
*** Bug 106785 has been marked as a duplicate of this bug. ***
*** Bug 106869 has been marked as a duplicate of this bug. ***
*** Bug 107010 has been marked as a duplicate of this bug. ***
I also run an amd64 entirely in 32-bit mode and continue to get this error even after recompiling qt and kdelibs. I get the following error: >checking for KDE... libraries /usr/kde/3.4/lib, headers /usr/kde/3.4/include >checking if UIC has KDE plugins available... no >configure: error: >you need to install kdelibs first However, I noticed that I'm running ~x86 and kdelibs-3.5_beta1-r1 is unmasked. I'm now rebuilding kdelibs-3.4* (and qt) and will retry kdebase-kioslaves (which is where I was hanging up).
(In reply to comment #28) > I also run an amd64 entirely in 32-bit mode and continue to get this error even > after recompiling qt and kdelibs. > > I get the following error: > >checking for KDE... libraries /usr/kde/3.4/lib, headers /usr/kde/3.4/include That did it. I had rebuilt kdelibs about a dozen times, each time the 3.5-beta, which did not satisfy the ebuild. Maybe the beta libs should stay masked until the whole package is "ready".
beta ebuilds *are* masked
*** Bug 108640 has been marked as a duplicate of this bug. ***
*** Bug 109564 has been marked as a duplicate of this bug. ***
*** Bug 112118 has been marked as a duplicate of this bug. ***
(In reply to comment #33) > *** Bug 112118 has been marked as a duplicate of this bug. *** Ok. I had searched the database by different keywords so I didn't find this previous file. Anyway, any idea how to fix this? How can I install kde on my Gentoo?
Recompile kdelibs every time you build qt. Simple.
(In reply to comment #35) > Recompile kdelibs every time you build qt. > Simple. Maybe you didn't read my file... I have made "emerge qt && emerge kdelibs && emerge kdebase" in one shot. Sorry for poor English. So, what more can I do?
This bug should probably be mentioned in pkg_postinst of Qt as people seem to hit this quite often.
(In reply to comment #36) > Maybe you didn't read my file... I have made "emerge qt && emerge kdelibs && > emerge kdebase" in one shot. Sorry for poor English. > > So, what more can I do? Your problem is related even if not identical, it seems for some reason Qt itself is compiled without opengl support, while the Qt plugins inside the Qt package are compiled with opengl support... I don't know what could cause this.
*** Bug 116071 has been marked as a duplicate of this bug. ***
(In reply to comment #38) > (In reply to comment #36) > > Maybe you didn't read my file... I have made "emerge qt && emerge kdelibs && > > emerge kdebase" in one shot. Sorry for poor English. > > > > So, what more can I do? > > Your problem is related even if not identical, it seems for some reason Qt > itself is compiled without opengl support, while the Qt plugins inside the Qt > package are compiled with opengl support... I don't know what could cause > this. I am sorry I am still here looking for help. At now I haven't yet been able to install KDE (kde-base/kde-meta). Have you found out some trick that permits me to have KDE in my Gentoo system? At least, do you know where I can ask for help? I have seen that all these unsuccessful tries to install that desktop manager have left some directories: /usr/kde/3.4, /usr/kde/3.5, /usr/qt/3 and /usr/lib/qt4/. The kde directories seem not to be populated as they should (I mean with all the subdirectories and files that they should contain), while it seems that the two qt directories are allright. Do you think that manually removing /usr/kde/3.4 and /usr/kde/3.5 could solve this issue? The only KDE package that seems correctly installed is kdelibs so i would precede the above-mentioned directories removings by a "emerge --unmerge kdelibs". Then, what do you think about the presence of qt version 3 and 4 at the same time? I really don't know anymore what to try. I have asked the Gentoo forum and this bugzilla too then I have searched through Google but I haven't found any solution. What does my particular Gentoo system have that forbids a simple "emerge kde-meta"? If I can't have KDE on Gentoo I will have to install some other distribution in order to get it. Please help me.
*** Bug 121475 has been marked as a duplicate of this bug. ***
I am having this problem too, it has taken down a perfectly functioning kde-3.5.1 setup and is mightily annoying. First, a blow-by-blow preamble: 1) Emerged qt-4.1.1 with world. Lost about half my widget-sets. 2) Re-emerged kdelibs per suggestion on Gentoo forums. Now nothing happens beyond kdm login, splash screen, ... 3) Tried to re-emerge kdebase-startkde, kdm, kwin, kdesktop ... all getting the same error (as in summary). 4) quickpkg'd and unmerged qt-4.1.1, re-emerged qt-3.3.6, qt-unixODBC-3.3.6 and kdelibs-3.5.1-r1 (all these were already installed). 5) Repeated step (3). This time kdebase-startkde compiled fine, but the others are still giving the same errors. Here's the thinggggy: ~ # emerge --info Portage 2.1_pre6-r3 (default-linux/x86/2005.0, gcc-4.1.0, glibc-2.3.6-r3, 2.6.15-gentoo-r7 i686) ================================================================= System uname: 2.6.15-gentoo-r7 i686 Intel(R) Celeron(R) CPU 2.60GHz Gentoo Base System version 1.12.0_pre16 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="-Os -march=pentium4 -mmmx -msse -msse2 -mfpmath=sse -fomit-frame-pointer -pipe -ffast-math -w" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /etc/make.conf /usr/NX/etc /usr/NX/home /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /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/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-Os -march=pentium4 -mmmx -msse -msse2 -mfpmath=sse -fomit-frame-pointer -pipe -ffast-math -w" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://ftp.mirrorservice.org/sites/www.ibiblio.org/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://brazil/gentoo-portage" USE="x86 X a52 aac acpi alsa apache2 apm arts asf avi berkdb bitmap-fonts bluetooth bzip2 cairo cdparanoia cdr crypt cups dbus dio doc dri dvd dvdread eds emboss encode ffmpeg flac flash foomaticdb fortran gdbm gif gpm gstreamer gtk2 hal i8x0 ieee1394 imagemagick imlib innodb ipv6 java javascript jpeg kde libg++ libwww mad matroska mikmod mmx motif mp3 mpeg msn mysql mysqli ncurses nls nptl nsplugin odbc ogg oggvorbis opengl oss pam pcmcia pcre pdflib perl php png ppds python qt quicktime readline samba sdl session sharedmem soap sockets spell sse sse2 ssl svg tcpd theora threads tiff truetype truetype-fonts type1-fonts unicode usb utf8 vcd vhosts vorbis wifi win32codecs xine xml2 xmlrpc xmms xsl xv xvid xvmc zlib elibc_glibc input_devices_keyboard input_devices_mouse input_devices_synaptics kernel_linux userland_GNU video_cards_i810" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LANG, LC_ALL, LDFLAGS, LINGUAS
To add to the above, I've now done the following: 1) emerge -C kdelibs kde-env arts qt-unixODBC qt 2) rm -rf /usr/qt /usr/kde /usr/lib/*qt* 3) emerge --oneshot kdelibs [pulls in the other packages] Despite this action (which I hoped was a thorough purge of all the problematic packages) the situation with attempting to merge any further kde packages is the same as before. Please can anyone suggest what action is needed in order to completely clear the decks and start from scratch? Where else can remnants of QT or KDE remain? Or is there something else confusing the matter? As the poster before me indicates, the above discussion does not help us lay-people to work around this issue, as it's over our heads. Some plain and simple guidance would be much appreciated.
Have you tried clearing out the portage cache before re-emerging as well? rm -rf /var/tmp/portage/qt* rm -rf /var/tmp/portage/kde*
(In reply to comment #44) > Have you tried clearing out the portage cache before re-emerging as well? > > rm -rf /var/tmp/portage/qt* > rm -rf /var/tmp/portage/kde* > Yes, I emptied /var/tmp/portage completely before emerge -c world. Is there something in the build of qt that we can point to as affecting this? Any particular USE-flags or such?
(In reply to comment #44) > Have you tried clearing out the portage cache before re-emerging as well? > > rm -rf /var/tmp/portage/qt* > rm -rf /var/tmp/portage/kde* > Yes, I emptied /var/tmp/portage completely before emerge -e world. Is there something in the build of qt that we can point to as affecting this? Any particular USE-flags or such?
Apologies for the double post. Was correcting it to say 'emerge -e world'. I've been googling for the error-string, and found a couple of interesting references: http://amarok.kde.org/amarokwiki/index.php/KDElibs_without_aRts http://fugitivethought.com/projects/amarokcompile/ Both pages give the cause of the error as qt being built without the -thread config flag (not sure whether this relates to USE="threads" or not). That interests me because the very beginning of this saga for me was rebuilding my system with glibc-2.4, which requires the global USE="nptlonly". Now, I know nought of threads. But the synchronicity of events here makes me wonder if there can be a connection. I still have both "nptl" and "threads" in my flags as well as "nptlonly" - should I have removed "threads" at the same time as adding "nptlonly"? Can this be related to this bug, or am I simply clutching at straws?
OK, now I have managed to get kde-base/* packages built (although I cannot launch KDE/KDM, but this may be more of a modular-X problem). I did: 1) emerge -C qt qt-unixODBC <left kdelibs in place this time> 2) echo "x11-libs/qt debug examples -nptlonly" >>/etc/portage/package.use <debug and examples were in case it still didn't work> 3) emerge kdebase-startkde (pulling in qt etc.) Will post back once I can confirm whether KDE is working.
Looks like my bug is different (has a different cause) to the OP's. I looked at the config.log (should have done this first of all) for one of the unsuccessful KDE packages, and saw this. ./configure: line 30790: 13426 Segmentation fault /usr/qt/3/bin/uic -L /usr/kde/3.5/lib/kde3/plugins/designer -nounload -impl actest.h actest.ui >actest.cpp I have been able to build a non-segfaulting UIC (and successfully compile KDE packages) by making qt with USE="debug" - don't ask me why this works, it just does. However, KDE is unable to start, and I suspect that the builds are still bad (X is fine, at least I can get twm up OK, but KDM or XDM -> startkde: forget it). Anyway, as my causes for the problem (and now disposition of the problem) seem to be different to the above, I'll start a new bug.
(In reply to comment #49) > Looks like my bug is different (has a different cause) to the OP's. > > I looked at the config.log (should have done this first of all) for one of the > unsuccessful KDE packages, and saw this. > > ./configure: line 30790: 13426 Segmentation fault /usr/qt/3/bin/uic -L > /usr/kde/3.5/lib/kde3/plugins/designer -nounload -impl actest.h actest.ui > >actest.cpp please take a look at his bug #126078 I think it's the same... > I have been able to build a non-segfaulting UIC (and successfully compile KDE > packages) by making qt with USE="debug" - don't ask me why this works, it just > does. > > However, KDE is unable to start, and I suspect that the builds are still bad (X > is fine, at least I can get twm up OK, but KDM or XDM -> startkde: forget it). > > Anyway, as my causes for the problem (and now disposition of the problem) seem > to be different to the above, I'll start a new bug.
(In reply to comment #50) > (In reply to comment #49) > please take a look at his bug #126078 > I think it's the same... > Thanks, I missed that one when searching and, yes, they do seem similar (though why can you build KDE and I can't?). My bug presents a method of preventing the segfault, so the real bug for me is the resulting b0rked KDE apps (apparently). In any case, if maintainers see fit to dup them, no problem by me. By the way, Caleb, can you explain the purpose of the qt-3.3.6-uic-fix.patch?
Yeah - when Qt 3.3.5 was released it completely broke uic files from the KDE project that had namespaced values in the includehints. This patch was quickly released to fix that. http://aseigo.blogspot.com/2005/09/qt-335-uic-problem-fix-patches.html
*** Bug 128010 has been marked as a duplicate of this bug. ***
Just an update that KDE 3.5.2 has entered the ~x86 tree, and I built it with a non-debug qt-3.3.6 and did not get the UIC error. However, I still can't start KDE and the errors are the same as before.
Robin, your bug is most definitely related. I did a glibc update a few days ago, and my Qt related programs stopped working as well (the underlying threading mechanism had changed). I ended up having to rebuild a couple of packages until I got everything to be happy again. I wondering if an "emerge -e system" or an "emerge -e world" will help you out.
(In reply to comment #55) > Robin, your bug is most definitely related. I did a glibc update a few days > ago, and my Qt related programs stopped working as well (the underlying > threading mechanism had changed). > I'm still open to that possibility, though as you can see, I've introduced a lot of confounds into the mix over the course of things. New X, new KDE... > I ended up having to rebuild a couple of packages until I got everything to be > happy again. > Can you elaborate? kde-packages, or toolchain/system/other packages? Did you follow a particular methodology to identify them? > I wondering if an "emerge -e system" or an "emerge -e world" will help you out. > I did this (both in fact)after the glibc-update, so my toolchain and world packages should all be nptlony now. Perhaps I'll repeat the process anyway just to pass the time...
*** Bug 135439 has been marked as a duplicate of this bug. ***
*** Bug 136086 has been marked as a duplicate of this bug. ***
*** Bug 147357 has been marked as a duplicate of this bug. ***
can someone plz post a make.conf that works to compile kdebase-startkde ive been struggling with this bug for a month now and its very frustrating
(In reply to comment #60) > can someone plz post a make.conf that works to compile kdebase-startkde ive > been struggling with this bug for a month now and its very frustrating > I don't know how I neglected to post this here before (maybe it ended up in a forums post instead) but I think I got over the problem by removing -Os (and possibly -ffast-math) from my CFLAGS. Hope that's some help.
*** Bug 149836 has been marked as a duplicate of this bug. ***
*** Bug 150204 has been marked as a duplicate of this bug. ***
*** Bug 150202 has been marked as a duplicate of this bug. ***
*** Bug 150364 has been marked as a duplicate of this bug. ***
*** Bug 154143 has been marked as a duplicate of this bug. ***
*** Bug 154384 has been marked as a duplicate of this bug. ***
*** Bug 154769 has been marked as a duplicate of this bug. ***
*** Bug 154724 has been marked as a duplicate of this bug. ***
*** Bug 158823 has been marked as a duplicate of this bug. ***
*** Bug 159190 has been marked as a duplicate of this bug. ***
(In reply to comment #71) > *** Bug 159190 has been marked as a duplicate of this bug. *** > This bug has been open for almost two years. Thirty-four people have been sufficiently troubled by it to submit bug reports, and all were simply marked "resolved, duplicate of bug 81066". This bug _blocks_ upgrade of all kde-related packages on my system. None of the suggested workarounds worked on my system. I think the severity of this bug should be raised, and priority given to finding a solution or work-around. Bob Barry
(In reply to comment #72) > None of the suggested workarounds worked on my system. I think the severity of > this bug should be raised, and priority given to finding a solution or > work-around. Because we have a s3cr1t solution carefully hidden in our knowledge base and just won't apply it because we love pointless duplicates filed by users who don't use search. P.S. Fix your line wrapping, the whole formatting in this bug is now broken.
Just rebuild kdelibs after you get this error. It happens when: - you change compiler; - you enable/disable opengl; - you enable/disable other features.
(In reply to comment #73) > (In reply to comment #72) > > None of the suggested workarounds worked on my system. I think the severity of > this bug should be raised, and priority given to finding a solution or > > work-around. > > Because we have a s3cr1t solution carefully hidden in our knowledge base and > just won't apply it because we love pointless duplicates filed by users who > don't use search. > > P.S. Fix your line wrapping, the whole formatting in this bug is now broken. > The ebuild said "re-emerge kdelibs"; I re-emerged both qt and kdelibs (many times). I searched for kdelibs, and found nothing similar. All description submitted with bug report has been obscured by the "duplicate" treatment. What "worksforyou" does NOT "workforme". Line wrapping is that of the bugzilla browser bug-entry facility.
*** Bug 159970 has been marked as a duplicate of this bug. ***
*** Bug 160334 has been marked as a duplicate of this bug. ***
*** Bug 165762 has been marked as a duplicate of this bug. ***
(In reply to comment #74) > Just rebuild kdelibs after you get this error. > It happens when: > - you change compiler; > - you enable/disable opengl; > - you enable/disable other features. This worked for me. Thanks.
I had the same problem installing net-p2p/Apollon on an AMD64 system but it was solved recompiling kdelibs.
(In reply to comment #79) > (In reply to comment #74) > > Just rebuild kdelibs after you get this error. > > It happens when: > > - you change compiler; > > - you enable/disable opengl; > > - you enable/disable other features. > > This worked for me. Thanks. > It _doesn't_ work for me. I'm reemerging kdelibs-3.5.6-r9 and is broken. The problem must be in QT, not in KDE. /usr/qt/3/bin/uic: symbol lookup error: /usr/qt/3/bin/uic: undefined symbol: _ZNK7QString3argExii Commenting deep from my ignorance... uic (the 'user_interface_compiler') is trying to compile something with id _ZNK7QString3argExii (like a control?!?) that doesn't exist anymore. The QT is broken, that uid should be there beforehand. Workaround please!!! I'm pulling my hair over here. And, the status has been changed to "RESOLVED WORKSFORME", well, I think the ebuild must be patched to make the checks... >> snippet << ../dcop/dcopidl2cpp/dcopidl2cpp --c++-suffix cpp --no-signals --no-stub kmainwindowiface.kidl rm -f kshortcutdialog_simple.cpp echo '#include <kdialog.h>' > kshortcutdialog_simple.cpp echo '#include <klocale.h>' >> kshortcutdialog_simple.cpp /usr/qt/3/bin/uic -nounload -tr tr2i18n -i kshortcutdialog_simple.h ./kshortcutdialog_simple.ui > kshortcutdi alog_simple.cpp.temp ; ret=$?; \ /usr/bin/perl -pe "s,tr2i18n( \"\" ),QString::null,g" kshortcutdialog_simple.cpp.temp | /usr/bin/perl -pe "s,tr2i18n( \"\"\, \"\" ),QString::null,g" | /usr/bin/perl -pe "s,image([0-9][0-9]*)_data,img\$1_kshortc utdialog_simple,g" | /usr/bin/perl -pe "s,: QWizard\(,: KWizard(,g" >> kshortcutdialog_simple.cpp ;\ rm -f kshortcutdialog_simple.cpp.temp ;\ if test "$ret" = 0; then echo '#include "kshortcutdialog_simple.moc"' >> kshortcutdialog_simple.cpp; else rm -f kshortcutdialog_simple.cpp ; exit $ret ; fi /usr/qt/3/bin/uic: symbol lookup error: /usr/qt/3/bin/uic: undefined symbol: _ZNK7QString3argExii make[3]: *** [kshortcutdialog_simple.cpp] Error 127 make[3]: *** Waiting for unfinished jobs.... make[3]: Leaving directory `/var/tmp/portage/kde-base/kdelibs-3.5.6-r9/work/kdelibs-3.5.6/kdeui' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/kde-base/kdelibs-3.5.6-r9/work/kdelibs-3.5.6/kdeui' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/kde-base/kdelibs-3.5.6-r9/work/kdelibs-3.5.6' make: *** [all] Error 2 !!! ERROR: kde-base/kdelibs-3.5.6-r9 failed. Call stack: ebuild.sh, line 1615: Called dyn_compile ebuild.sh, line 972: Called qa_call 'src_compile' ebuild.sh, line 44: Called src_compile kdelibs-3.5.6-r9.ebuild, line 151: Called kde_src_compile kde.eclass, line 170: Called kde_src_compile 'all' kde.eclass, line 340: Called kde_src_compile 'myconf' 'configure' 'make' kde.eclass, line 336: Called die !!! died running emake, kde_src_compile:make !!! If you need support, post the topmost build error, and the call stack if relevant. !!! A complete build log is located at '/var/tmp/portage/kde-base/kdelibs-3.5.6-r9/temp/build.log'.
*** Bug 181997 has been marked as a duplicate of this bug. ***
*** Bug 188486 has been marked as a duplicate of this bug. ***
I had this problem with k9copy. The bug was marked as duplicate. I ran the following based on the first comment: kde_cv_uic_plugins=yes emerge --resume and k9copy compiled fine.
*** Bug 206111 has been marked as a duplicate of this bug. ***
*** Bug 214447 has been marked as a duplicate of this bug. ***
Just a note: AMD64 Turion system gcc 4.3.1. I got this problem and resolved it by changing cflags from -os to -o2. Pain bug, IMO. Raydude
Came across the same problem with kpdf 3.5.10. kde_cv_uic_plugins=yes emerge --resume worked for me too.
*** Bug 257387 has been marked as a duplicate of this bug. ***
*** Bug 258379 has been marked as a duplicate of this bug. ***
Folks, I am re-opening this since we get hit of this bug quite often latetly I would like some extra info to do some tests though. So I would like somebody who encounters this problem to attach the config.log file for now
There's nothing to be done about this issue. It happens always, when switching anything in your system affecting the Qt 3 build key, as you can read following the url in comment 4.
*** Bug 256659 has been marked as a duplicate of this bug. ***
*** Bug 258946 has been marked as a duplicate of this bug. ***
Created attachment 182154 [details] config.log of a failed build This is the config.log of a failed build of media-sound/noteedit (version 2.8.1-r2) on an amd64 system.
I had the same issue with noteedit-2.8.1-r2 and rebuilding kdelibs:3.5 fixed it.
I still have the problem with noteedit-2.8.1-r2 I have re-emerged kdelibs-4.2.0-r3, but that does not help.
You should re-emerge kdelibs:3.5 and not kdelibs:4.2
My system is an x86_64, using -Os and has about 1000 packages, including qt:3.5, qt4 and a bunch of crossdev toolchains. I have done: emerge -eD --keep-going world 8 times now, the only packages that can't be rebuilt are the ones which depend on something that is affected by this. (kde stuff) Reading some previous comments, I wonder if this is being caused by a mismatch in optimisation level, where one of the involved packages forces -O2 on something. (since I use -Os normally) Can someone clarify this, since I would consider it a serious bug if qt/kde refuses to load a plugins that are compiled with different optimisation settings. This would be creating a problem where there isn't any. Where can I find the build key that qt was built with? How do I know which build key a kde ebuild is attempting to use when merging?
Sorry, I mean qt-3.3.8b-r1 (I've tried qt-3.3.8b-r2 as well, with same results) And obviously, re-emerging kdelibs does not help.
I could not emerge kde-misc/basket-1.0.3.1 because I got the Segmentation fault of /usr/qt/3/bin/uic. This is on amd64 in 64-bit mode with x11-libs/qt-3.3.8b-r1, and kde-base/kdelibs-3.5.10-r6. All the versions are supposed to be stable. My CFLAGS="-march=athlon64 -Os -fomit-frame-pointer -pipe". I temporarily change -Os to -O2 in my CFLAGS and reemerged kdelibs. Then I changed it back to -Os, and now I could successfully emerge basket without uic getting a segmentation fault. So a fix for the segmentation fault bug seams to be forcing CFLAGS -Os to -O2 in kdelibs for amd64. The "need to rebuild kdelibs after random change" bug is probably not affected by this -Os problem, so they are really two different bugs.
(In reply to comment #101) > I could not emerge kde-misc/basket-1.0.3.1 because I got the Segmentation fault > of /usr/qt/3/bin/uic. This is on amd64 in 64-bit mode with > x11-libs/qt-3.3.8b-r1, and kde-base/kdelibs-3.5.10-r6. All the versions are > supposed to be stable. My CFLAGS="-march=athlon64 -Os -fomit-frame-pointer > -pipe". > > I temporarily change -Os to -O2 in my CFLAGS and reemerged kdelibs. Then I > changed it back to -Os, and now I could successfully emerge basket without uic > getting a segmentation fault. So a fix for the segmentation fault bug seams to > be forcing CFLAGS -Os to -O2 in kdelibs for amd64. Are you sure basked, kdelibs and the qt deps were all built with the same gcc version? Using different gcc versions can cause these type of issues.
> Are you sure basked, kdelibs and the qt deps were all built with the same gcc > version? Using different gcc versions can cause these type of issues. I have the same issue, this is a *REAL* bug. The packages cannot be built with only -Os. At least Qt and/or kdelibs need a different (-O2) setting. Something is terribly wrong with the idea that Qt somehow needs to magically manage build options for you, it's more likely to cause worse bugs than it ever hopes to solve. There needs to be a way to switch off all Qt plugin-loader runtime checks. (and obviously these build time checks as well)
(In reply to comment #102) > Are you sure basked, kdelibs and the qt deps were all built with the same gcc > version? Using different gcc versions can cause these type of issues. Yep, I'm quite sure! I reemerged all three packages eight times, with all eight possible combinations of -Os and -O2. :-) For qt and basket the -O flag didn't matter, as long as kdelibs was compiled with -O2.
rant-ish... As a developer, it is my opinion that ebuilds should never(!) interfere with the choices of compiler, options and environment, since I like to change those things a on a per package basis. It's nice to have a blacklist in a package, where the package can give a useful error message if the environment is somehow totally wrong (and there is no way in the world that it will work after building) But a whitelist... to assume all gentoo environments can be known, to me it sounds like a mistake. Most of the time, when I use gentoo, I'm using experimental stuff, Is it not likely that a large amount of gentoo users are using various experimental gcc or glibc? It's also very likely that hardened users insert uncommon compiler flags on select packages. Now, I don't know whether to file this as a bug upstream or in gentoo, since it should be relatively easy to patch out the evil code in Qt ;p I'd guess that the Ubuntu people want this in Qt, and that it will stay upstream. Thank you for your time, love you guys :).
Try adding "-opengl" to qt's USE flags, re-emerging qt, then re-emerging kdelibs. That worked for me.
