Hello, first: shame on me. I haven't tested properly QT4.x before I marked it stable. I suspended this bug report just to long now. The problem: Many QT 4 application do "segmentation fault" on startup. This included Designer and Assistant for example. I'll give some details in an comment on this bug soon. I've already opened an upstream bug report awhile ago: http://www.trolltech.com/developer/task-tracker/index_html?id=133870&method=entry As you can see upstream is not interested in fixing this.. I'm going to remove the ppc64 keyword from QT4 and all apps using it directly and add qt4 to use.mask for the time being. Sorry for the trouble I created..
I'll await your pending comments, but do you have any backtraces that might show where the seg faults are coming from?
I had to remove ~ppc64 keywords from x11-libs/qwt-5*. I've use.masked qt4 in ppc64 profiles and removed ~ppc64 from qt4*.
(In reply to comment #1) > I'll await your pending comments, but do you have any backtraces that might > show where the seg faults are coming from? yes, this one is a quick bt (I'll try to get a 'deeper' one later): Program terminated with signal 11, Segmentation fault. #0 0x000004000145de2c in ._ZN6QMutex4lockEv () from /usr/lib/qt4/libQtCore.so.4 Thread 1 (process 23476): #0 0x000004000145de2c in ._ZN6QMutex4lockEv () from /usr/lib/qt4/libQtCore.so.4 No symbol table info available. #1 0x00000400014b6c94 in ._ZN26QAbstractFileEngineHandlerC2Ev () from /usr/lib/qt4/libQtCore.so.4 No symbol table info available. #2 0x00000400014e6150 in ._ZN14QTemporaryFile15createLocalFileER5QFile () from /usr/lib/qt4/libQtCore.so.4 No symbol table info available. #3 0x00000400014e6240 in ._Z15qInitResourceIOv () from /usr/lib/qt4/libQtCore.so.4 No symbol table info available. #4 0x0000000000000000 in ?? () No symbol table info available. and this is the one I've sent upstream some while ago (note: that was still gcc 3.4.6): #0 0x0000040001303434 in ._ZN6QMutex4lockEv () from /usr/lib64/qt4/libQtCore.so.4 #1 0x000004000135c240 in ._ZN26QAbstractFileEngineHandlerC2Ev () from /usr/lib64/qt4/libQtCore.so.4 #2 0x000004000138bdb8 in ._ZNK19QResourceFileEngine17supportsExtensionEN19QAbstractFileEngine9ExtensionE () from /usr/lib64/qt4/libQtCore.so.4 #3 0x00000fffffba7688 in ?? () #4 0x00000400017701f8 in std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_Rep::_S_empty_rep_storage () from /usr/lib/gcc/powerpc64-unknown-linux-gnu/3.4.6/libstdc++.so.6 #5 0x00000400019be060 in _res () from /lib/libc.so.6 #6 0x0000000000000000 in ?? ()
Failing in QMutex::lock, most likely on QAtomic stuff, since that's assembly level code that's platform specific. The configure script shows it recognizes ppc64 as the "powerpc" platform, which is the same as what's recognized ppc32. It would use the assembly in "src/corelib/arch/qatomic_powerpc.h", which shows that it also does a check for __64BIT__ to be defined if Q_CC_GNU is also set. I have no idea whether or not the assembly is valid, but I would assume it is. A couple of thoughts: 1) Can you verify when the Qt emerge starts it identifies your platform as 64 bit power pc? 2) I assume you're using gnu tools, such that Q_CC_GNU would be set, and __64BIT__ would be defined? 3) Are there any other strange issues with using the C p_thread_* functions on this platform that might be causing the issue? 4) barring any of that, any way you can rebuild Qt with debugging symbols nostripped?
> 1) Can you verify when the Qt emerge starts it identifies your platform as 64 > bit power pc? from the emerge process: [...] Determining system architecture... (Linux:2.6.21.1:ppc64) 64-bit PowerPC (powerpc) 'powerpc' is supported System architecture: 'powerpc' -fvisibility support enabled. sse support disabled. [...] > 2) I assume you're using gnu tools, such that Q_CC_GNU would be set, and > __64BIT__ would be defined? Q_CC_GNU is defined: G5 global # pwd /var/tmp/portage/x11-libs/qt-4.2.3-r1/work/qt-x11-opensource-src-4.2.3/src/corelib/global G5 global # cat test.c #include "qglobal.h" #include <iostream> int main(int argc, char *argv[]) { #ifdef Q_CC_GNU std::cout << "Q_CC_GNU defined\n"; #endif #ifdef __64BIT__ std::cout << "__64BIT__ defined\n"; #endif return 0; } G5 global # vim test.c G5 global # cat test.c G5 global # pwd /var/tmp/portage/x11-libs/qt-4.2.3-r1/work/qt-x11-opensource-src-4.2.3/src/corelib/global G5 global # cat test.c #include "qglobal.h" #include <iostream> int main(int argc, char *argv[]) { #ifdef Q_CC_GNU std::cout << "Q_CC_GNU defined\n"; #endif return 0; } G5 global # g++ -o test test.c -I../../../include/ G5 global # ./test Q_CC_GNU defined G5 global # I'm not sure about __64BIT__ yet, will look for it later: # grep -R __64BIT__ * src/corelib/arch/qatomic_powerpc.h:#ifdef __64BIT__ # > 3) Are there any other strange issues with using the C p_thread_* functions on > this platform that might be causing the issue? I don't know about issues, but that doesn't mean there aren't any. > 4) barring any of that, any way you can rebuild Qt with debugging symbols > nostripped? currently building
Created attachment 119466 [details] qt-4.2.3-r1-ppc64-backtrace.txt this is a better backtrace.
thinking out loud here: one thing that looks odd to me is this: #2 0x00000400018ae224 in QMutexLocker (this=0xfffff8b85e8, m=0x100f203000000000) #3 0x00000400019239e4 in QAbstractFileEngineHandler (this=0x100f2010) io/qresource.cpp:975 has this: Q_GLOBAL_STATIC(QResourceFileEngineHandler, resource_file_handler) creating the resource in frame #4 (and carried into frame #3). The mutex m in frame #2 is created with: Q_GLOBAL_STATIC_WITH_ARGS(QMutex, fileEngineHandlerMutex, (QMutex::Recursive)) at io/qabstractfileengine.cpp:107 But why are their addresses so far off? Does the Q_GLOBAL_STATIC_WITH_ARGS have an endianness issue?
app-office/lyx-1.5.0 depends on qt4, too. We need to add keyword there, once qt4 is ~ppc64.
curious if you have had any luck with qt-4.3.1 ?
looks like we're not alone on this, as it seems to be broken for others as well based on a recent email to qt-interest. They cited this bug: http://bugzilla.redhat.com/246324
Created attachment 128935 [details, diff] qt-4.3.1-powerpc64.patch this patch fixed the segfault. caleb: I've sent this patch upstream. do you want to include this patch in the ebuild, or do you want me to do so?
please go ahead and add it in. thanks!
patch added a few days ago. mark bug as FIXED.
