No qt-based application properly works after upgrade. Either doesn't show at all (e.g. fwbuilder) or trying to open a dialog (Help/About, File/Open, etc) makes the app stuck. Rebuilding the apps didn't help. Same with 3.3.4-r2. 3.3.3 is fine. Reproducible: Always Steps to Reproduce:
> Same with 3.3.4-r2 Sorry, I meant same with 3.3.4-r3.
What's your 'emerge info'?
3.3.4-r2 and -r3 work great here.
> What's your 'emerge info'? Portage 2.0.51.19 (default-linux/amd64/2004.3, gcc-3.3.4, glibc-2.3.4.20041102-r0, 2.6.9-gentoo-r12 x86_64) ================================================================= System uname: 2.6.9-gentoo-r12 x86_64 AMD Opteron(tm) Processor 244 Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 9 2005, 10:37:01)] ccache version 2.3 [enabled] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.5, 1.7.9-r1, 1.6.3, 1.8.5-r3, 1.4_p6, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.4.21-r1 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CFLAGS="-O2" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.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/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/init.d /etc/terminfo /etc/env.d" CXXFLAGS="-O2" DISTDIR="/.n/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox" GENTOO_MIRRORS="http://www.ibiblio.org/pub/Linux/distributions/gentoo http://mirror.hamakor.org.il/pub/mirrors/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/local/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 16bit X Xaw3d a52 alsa bash-completion berkdb bidi bitmap-fonts bonobo cdf cdparanoia cdr crypt css cups curl divx4linux dv dvd encode esd exif f77 fam fame fftw flac font-server foomaticdb fortran fpx gdbm gif gimp gimpprint gnome gphoto2 gpm graphviz gs gsl gstreamer gtk gtk2 gtkhtml guile idea imagemagick imlib imlib2 jp2 jpeg kde lcms ldap libwww lzw lzw-tiff mad mbox mikmod motif mozilla moznoirc mozp3p mozsvg mozxmlterm mp3 mpeg4 ncurses netcdf oggvorbis opengl pam pdflib perl plotutils png ppds python qt readline samba scanner sdl slang sqlite ssl svg t1lib tcltk tcpd tetex tiff transcode transparent-proxy truetype truetype-fonts type1 type1-fonts usb userlocales wmf xml xml2 xmms xpm xrandr xv xvid zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS
The first thing that comes to my mind is that using gcc-3.3 on amd64 is officially deprecated (http://www.gentoo.org/proj/en/base/amd64/technotes.xml?part=2&chap=3)
> gcc-3.3 on amd64 is officially deprecated As a matter of the fact, qt-3.3.4-r2 was compiled with 3.4.3. I switched back to gcc-3.3 only yesterday to compile something that didn't compile with 3.4.
Can you try running some application within strace to see what's causing the problem internally?
Tony: Aside from this issue, please set AUTOCLEAN in your make.conf to yes. It's a deprecated option, which caused all sorts of hard to resolve bugs in the past, if set to no.
^^ Sorry, wrong bug.
> Can you try running some application within strace to see what's causing the problem internally? It waits forever in a select() call. I'll attach a sample strace output.
Created attachment 52914 [details] strace output of Qt's assistant
Looks to me like the socket its reading/writing to is /tmp/.X11-unix/X0, so perhaps if you kill X, delete /tmp/.X11-unix (and perhaps other stuff in /tmp) and then restart X it will work better.
Also, why in the strace output there's "/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.4/libstdc++.so.5" if qt is compiled with gcc-3.4.3, as you said on comment 6?
Caleb Tennis wrote: > Looks to me like the socket its reading/writing to is /tmp/.X11-unix/X0, so perhaps if you kill X, delete /tmp/.X11-unix (and perhaps other stuff in /tmp) and then restart X it will work better. Why would 3.3.3 be different then? Anyway, did it; and it didn't help. Gregorio Guidi wrote: > Also, why in the strace output there's /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.4/libstdc++.so.5" if qt is compiled with gcc-3.4.3, as you said on comment 6? I said it _was_ compiled with 3.4.3, but then I switched to gcc-3.3.4. So when asked to strace the thing, I remerged qt-3.3.4 again, now with gcc-3.3.4. The apps get stuck when they try to open DialogWindow (or whatever this's called in Qt). The MainWindow loads fine; in cases of e.g. fwbuilder or assistant which want to ask something before managing the main window, nothing appear at all. Are any of you running amd64?
For proper debbuging of the issue please switch to gcc 3.4 an recompile everything that was compiled with gcc 3.3 with gcc 3.4. To know which programs should be recompiled and in which order you can run: # revdep-rebuild -X --soname libstdc++.so.5
OK, it appears the apps are NOT get stuck. What happens really, is that the dialogs are placed out of the screen (e.g. fwbuilder's initial dialog has geometry 2x7+0+1781 on my 1280x1024 screen), so it's invisible. Now, this happens with fvwm. I tried other WMs and everything is OK, so this might be a fvwm bug (or may be other WMs simply ignore bogus placement requests). Still, no other toolkit causes this (neither does qt < 3.3.4), so I'd like to understand what really changed in 3.3.4 WRT dialog placement.
unlikely this is an fvwm bug, although fvwm would attempt to honour any strange PPosition requests. Please open an FvwmConsole and type "BugOpts ExplainWindowPlacement On", open one of these dialogs then look at the console (if you start fvwm via startx, change back to the console you started it from..eg ctrl+alt+f1, if you use a dm, try looking in ~/.xsession-errors). Fvwm will try to explain why it placed a window where it did.
Tavis: This is the debug output: [FVWM][__explain_placement]: placed new window 0x20004ea 'Welcome to Firewall Builder': desk 0 (current desk) current page position 0 1781 (used user specified position) I tried setting Style "*" NoUSPosition but it makes no difference (for Qt dialogs, that is; placement of "good X citizens" like e.g. gkrellm IS affected). Whether NoUSPosition is set or not, the fvwm's debug output is exactly the same (which is strange). I also played with every setting mentioned in the man page related to placement, all in vain. The only way to force the Qt dialogs appear with reasonable geometry is to set EwmhBaseStruts to obscure entire screen, e.g. EwmhBaseStruts 400 400 400 400 Then, the dialogs are placed correctly: [FVWM][__explain_placement]: placed new window 0x22004ea 'Welcome to Firewall Builder': desk 0 (current desk) current page position 400 581 (used user specified position) But this, of course, breaks fvwm's SmartPlacement altogether. So, apparently, Qt is doing some dirty calculations WRT dialog placement, trying to be smarter than WM is.
Well it looks like the dialogs are requesting a strange position, you can confirm by running xprop WM_NORMAL_HINTS and clicking on a dodgy dialog. fvwm+qt-3.3.4 work fine here btw.
> Well it looks like the dialogs are requesting a strange position, you can > confirm by running xprop WM_NORMAL_HINTS and clicking on a dodgy dialog. Indeed: WM_NORMAL_HINTS(WM_SIZE_HINTS): user specified location: 0, 1781 program specified location: 0, 1781 user specified size: 430 by 199 program specified size: 430 by 199 program specified minimum size: 428 by 192 window gravity: NorthWest > fvwm+qt-3.3.4 work fine here btw. How strange... Are you on amd64? My fvwm ebuild is: x11-wm/fvwm-2.5.12 +bidi -debug +gtk +gtk2 +imlib -nls +perl +png +readline -rplay -stroke +tcltk +truetype -xinerama and qt's: x11-libs/qt-3.3.4-r2 +cups -debug -doc (-firebird) +gif -immqt -immqt-bc -ipv6 -mysql -nas -odbc +opengl -postgres +sqlite -xinerama +zlib
*** Bug 84545 has been marked as a duplicate of this bug. ***
Reverting to qt-3.3.3 solves the problem, so I believe that since qt-3.3.4 works OK for Evgeny Stambulchik (architecture not specified but probably x86) there has been an addition to qt that is not 64-bit clean. I would respectfully suggest that qt-3.4.2 ebuild be marked KEYWORDS ~amd64 until this is fixed. Regards, Roger (reporter of http://bugs.gentoo.org/show_bug.cgi?id=84545 marked as a duplicate of this one).
> since qt-3.3.4 works OK for Evgeny Stambulchik Nope. It's Tavis for whom it worked.
I had a similar problem when upgrading to qt-3.3.4-r2. I'm currently compiling 3.3.4-r3 and hoping that will fix things, otherwise i guess i'll have to revert to an older version of qt. All qt apps on my system won't display icons correctly, although windows do seem to be drawn correctly. I'm using gcc-3.4.3 on amd64. # emerge info Portage 2.0.51.19 (default-linux/amd64/2004.3, gcc-3.4.3, glibc-2.3.4.20041102-r1, 2.6.11-gentoo-r6 x86_64) ================================================================= System uname: 2.6.11-gentoo-r6 x86_64 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 9 2005, 17:34:50)] distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.14 virtual/os-headers: 2.6.8.1-r4 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CFLAGS="-O2 -pipe" CHOST="x86_64-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.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /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="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox strict" GENTOO_MIRRORS="ftp://ftp.ndlug.nd.edu/pub/gentoo ftp://chod.cwru.edu/gentoo http://chod.cwru.edu/gentoo ftp://gentoo.chem.wisc.edu/gentoo/ ftp://mirrors.tds.net/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnowext X acpi aim alsa amd64 arts avi bash-completion berkdb bitmap-fonts calender cdr crypt cups curl dvd dvdread esd fam fbcon flac font-server fortran ftp gif gpm gstreamer gtk imagemagick imap imlib ipv6 java jp2 jpeg junit kde libwww logitech-mouse lzw lzw-tiff mad motif mozilla mp3 mpeg msql multilib mysql ncurses nls nptl nvidia ogg oggvorbis opengl oss pam pdflib perl png posix python qt quicktime readline samba sdl sockets spell spl sqlite ssl tcpd tetex tiff tokenizer truetype truetype-fonts type1-fonts usb userlocales videos vorbis wxwindows xine xinerama xml2 xmms xpm xrandr xv zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
I have similar problem with Qt and fvwm (actually more close to bug 79599) and amd64 platform. fvwm-2.5.12 qt-3.3.4-r2 I'll attacv 'emerge info below', but as a quick remark - I'm not using -Os, just -O2 as my optimization flag. Two Qt applications - skype (tried both shared and static binary of 1.1.0.3 version from gentoo site, as well as directly from skype.com) and camstream freeze after opening the first window under fvwm. Both applications work fine not only under KDE, but also when there is no window manager at all (failsafe session). Symptoms: loading skype, first window opens, however the login window which skype opens then never comes up. Main window is non responsive - neither buttons, more menus, nor even window buttons. Needs Cntrl-C to be killed. Focus also seems to behave strange. Hovering mouse over skype window, and not leaving it, I can sometimes change the color of window title bar to 'unfocused' one. Camstream is similar. First window opens, and menus are working. However if I choose 'open viewer' which should about new configuration widow, it does not appear and main window gets frozen. Need Cntrl-C as well. So it seems these two Qt application under fvwm fail when one needs to open new window from within Qt window. Again, in the absence of window manager both work fine. Also, as a side remark. I have a problem with /usr/qt/3/lib been absent, and I created a symlink /usr/qt/3/lib64 -> /usr/qt/3/lib ------------- Here is my emerge info Portage 2.0.51.19 (default-linux/amd64/2005.0, gcc-3.4.3, glibc-2.3.4.20041102-r1, 2.6.11-gentoo-r7 x86_64) ================================================================= System uname: 2.6.11-gentoo-r7 x86_64 AMD Opteron(tm) Processor 248 Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 12 2005, 22:24:07)] distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.4-r1 sys-apps/sandbox: [Not Present] sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.8.1-r4 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CFLAGS="-O2" CHOST="x86_64-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/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/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X acpi alsa arts berkdb bitmap-fonts cdparanoia cdr crypt cups curl dvd dvdr fam font-server foomaticdb fortran gif gpm gtk gtk2 imagemagick imlib java jp2 jpeg kde libwww lzw lzw-tiff motif mozilla mp3 ncurses nls nptl opengl oss pam perl png ppds python qt readline sdl server spell ssl tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts unicode usb xinerama xml2 xmms xpm xrandr xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
I'd say this bug looks pretty much the same as bug #79599 (as mensioned by comment 25)
*** Bug 79599 has been marked as a duplicate of this bug. ***
Reassigning. After looking at the patch for windowmaker: http://article.gmane.org/gmane.compw.window-managers.windowmaker.devel/749 (Thanks for the pointer, Patrick.) it is reasonable to think that fvwm has a similar problem.
There seems to be a bug report reported to the fvwm bugtracking system also. At least it exhibits the same behaviour. http://www.fvwm.org/cgi-bin/fvwm-bug/incoming?id=1686
does fvwm-2.5.13-r1 solve it?
It seems 2.5.13-r1 hasn't hit the mirrors yet (as of 3 minutes ago)... Doesn't seem to be available over CVS either (according to http://www.gentoo.org/cgi-bin/viewcvs.cgi/x11-wm/fvwm/)
2.5.13-r1 is now on the mirrors and I've got it installed. Seems to work just dandy! Thanks Tavis!
Tavis, 2.5.13-r1 indeed seems to fix the bug. However, it no longer allows me to override icon settings. E.g. Style "*Thunderbird*" Icon thunderbird.xpm is ignored and the ugly built-in icon of the Gentoo thunderbird ebuild is shown instead. Any idea what has changed?
Hmm, not sure what would have changed that, have you tried using Style Thunder.. IconOverride, Icon foo.xpm
Thanks! IconOverride fixed this. It worked fine without it prior to upgrading. Anyway, thanks again.
Okay marking FIXED, thanks everyone :)
