Bug 246324

It's worse than that, testing on ppc64/rawhide (thanks dwmw!), pretty much any
qt4-related binary segfaults (immediately), it's easier to list those that do
*not* seg fault: qmake, moc, rcc, uic

ugh.

Looks like we'll have to ExcluceArch this for now, it's fundamentally broken,
and I can't find anything simple or obvious that's wrong.

Glad to know we're not the only ones seeing this:
http://bugs.gentoo.org/show_bug.cgi?id=178779
:)

Reported issue upstream to Trolltech, will supply reference details when/if I
get a reply.

I think I might have found the issue, __might__

In /usr/include/Qt[Core]/qatomic_powerpc.h

There is the following code:

#ifdef __64BIT__
#  define LPARX "ldarx"
#  define CMPP  "cmpd"
#  define STPCX "stdcx."
#else
#  define LPARX "lwarx"  
#  define CMPP  "cmpw"
#  define STPCX "stwcx."   
#endif

However __64BIT__ doesn't get defined in any QT header, and is not a standard
gcc define, compiling this on my x86_64:

#include <stdio.h>

int main(void)
{
#ifdef __64BIT__
    printf("64 bit\n");
#else
    printf("32 bit\n");
#endif
    return 0;
}

Results in an output of "32 bit", changing the "#ifdef __64BIT__ to
"#ifdef __powerpc64__" thus would be a very good idea and _might_ fix the issues
you are seeing.

I forgot, you might want to check for __64BIT__ in the sources too, I only
checked the headers to see if there was something fishy there and found this.

Created attachment 168244 [details]
proposed patch based on comment #5

Hello,

I'm the Gentoo developer, who has opened the bug mentioned in comment #3 and I
have just finished compiling qt 4.3.1 with the attached patch, which is based
on the findings in comment #5.

as you can see qt does now run on my ppc64 machine:
http://www.unixforces.net/~markus/screenshots/screenshot-2007-08-23.png

I've been in contact with upstream and they've opened this public bug on their
tracker:

http://trolltech.com/developer/task-tracker/index_html?id=133870&method=entry

unfortunately there is neither much information nor a way to submit patches in
their tracker, so I'll email it directly to the developer I've been in contact
with (all credits to Hans de Goede of cause ;-) ).

Regards,

-markus

P.S.: I feel dumb not having this fixed months ago ;-)

(In reply to comment #7)
> Created an attachment (id=168244) [edit]
> proposed patch based on comment #5
> 
> Hello,
> 
> I'm the Gentoo developer, who has opened the bug mentioned in comment #3 and I
> have just finished compiling qt 4.3.1 with the attached patch, which is based
> on the findings in comment #5.
> 
> as you can see qt does now run on my ppc64 machine:
> http://www.unixforces.net/~markus/screenshots/screenshot-2007-08-23.png
> 

Wow, so you mean my little "instinctive" grep through the headers found the bug :)

Glad to hear that, I guess thats experience with lots of ppc 64 compile errors
paying off. Since Fedora is building for powerpc64 I've had many of my packages
failing, because often they don't check for __powerpc64__ but only for
__powerpc__ and __x86_64__. So I though that qt would probably have something
like a config.h with some arch specific defines and that I should compare the
x86_64, ppc and ppc64 versions of that file, so I started grepping through the
includes as shipped on ppc64 and thats how I found this.

Anyways I'm glad to hear that my little investment of time has actually resulted
in a fix for this.

I opted for this instead:
-#ifdef __64BIT__
+#if defined(__64BIT__) || defined(__powerpc64__)
there may be some reason Trolltech wanted the check for __64BIT__ in there (some
other platform(s)?

Oh, and many thanks Markus!

(In reply to comment #8)
> Wow, so you mean my little "instinctive" grep through the headers found the bug :)

I wish I had your instinct :-)

(In reply to comment #9)
> I opted for this instead:
> -#ifdef __64BIT__
> +#if defined(__64BIT__) || defined(__powerpc64__)
> there may be some reason Trolltech wanted the check for __64BIT__ in there (some
> other platform(s)?

I'll let upstream decide that. But as there are _no_ other references for __64BIT__ I would think it's save 
to nuke that.

After reporting upstream, and told this would be assigned issue #176132, it
seems not to be available (yet), on
http://trolltech.com/developer/task-tracker

but I *did* find an old, pretty much identical report:
http://trolltech.com/developer/task-tracker/index_html?method=entry&id=133870

qt4-4.3.1-3.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

Has this update been pushed into rawhide?  I'm still having problems building 
qgis on ppc64:

http://koji.fedoraproject.org/koji/getfile?taskID=177033

[ 96%] /usr/bin/cmake -E 
cmake_progress_report /builddir/build/BUILD/qgis-0.9.0/CMakeFiles 
[ 96%] [ 96%] [ 96%] Generating qgis_pt_BR.qm
cd /builddir/build/BUILD/qgis-0.9.0/i18n 
&& /usr/lib64/qt4/bin/lrelease -verbose /builddir/build/BUILD/qgis-0.9.0/i18n/qgis_pt_BR.ts -qm /builddir/build/BUILD/qgis-0.9.0/i18n/qgis_pt_BR.qm
Generating qgis_vi.qm
cd /builddir/build/BUILD/qgis-0.9.0/i18n 
&& /usr/lib64/qt4/bin/lrelease -verbose /builddir/build/BUILD/qgis-0.9.0/i18n/qgis_vi.ts -qm /builddir/build/BUILD/qgis-0.9.0/i18n/qgis_vi.qm
Generating qgis_sk.qm
cd /builddir/build/BUILD/qgis-0.9.0/i18n 
&& /usr/lib64/qt4/bin/lrelease -verbose /builddir/build/BUILD/qgis-0.9.0/i18n/qgis_sk.ts -qm /builddir/build/BUILD/qgis-0.9.0/i18n/qgis_sk.qm
Generating qgis_it.qm
cd /builddir/build/BUILD/qgis-0.9.0/i18n 
&& /usr/lib64/qt4/bin/lrelease -verbose /builddir/build/BUILD/qgis-0.9.0/i18n/qgis_it.ts -qm /builddir/build/BUILD/qgis-0.9.0/i18n/qgis_it.qm
/bin/sh: line 1: 19609 Segmentation 
fault      /usr/lib64/qt4/bin/lrelease -verbose /builddir/build/BUILD/qgis-0.9.0/i18n/qgis_pt_BR.ts -qm /builddir/build/BUILD/qgis-0.9.0/i18n/qgis_pt_BR.qm
make[2]: *** [i18n/qgis_pt_BR.qm] Error 139
make[2]: *** Waiting for unfinished jobs....
/bin/sh: line 1: 19611 Segmentation 
fault      /usr/lib64/qt4/bin/lrelease -verbose /builddir/build/BUILD/qgis-0.9.0/i18n/qgis_vi.ts -qm /builddir/build/BUILD/qgis-0.9.0/i18n/qgis_vi.qm
make[2]: *** [i18n/qgis_vi.qm] Error 139
/bin/sh: line 1: 19613 Segmentation 
fault      /usr/lib64/qt4/bin/lrelease -verbose /builddir/build/BUILD/qgis-0.9.0/i18n/qgis_sk.ts -qm /builddir/build/BUILD/qgis-0.9.0/i18n/qgis_sk.qm
make[2]: *** [i18n/qgis_sk.qm] Error 139
/bin/sh: line 1: 19615 Segmentation 
fault      /usr/lib64/qt4/bin/lrelease -verbose /builddir/build/BUILD/qgis-0.9.0/i18n/qgis_it.ts -qm /builddir/build/BUILD/qgis-0.9.0/i18n/qgis_it.qm
make[2]: *** [i18n/qgis_it.qm] Error 139
make[2]: Leaving directory `/builddir/build/BUILD/qgis-0.9.0'
make[1]: *** [i18n/CMakeFiles/translations.dir/all] Error 2
make[1]: Leaving directory `/builddir/build/BUILD/qgis-0.9.0'
make: *** [all] Error 2

Yes, since 4.3.1-3, and updated for s390x in 4.3.1-4, changelog:

* Thu Sep 13 2007 Than Ngo <than> -  4.3.1-4
...
- fixed bz249242, designer4 - segmentation fault on s390x

* Wed Aug 23 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 4.3.1-3
- ppc64 patch (#246324)

Can't access koji atm.

Is the failure repeatable?  (I've seen a build fail, then resubmit, and then it
works... ??)

(In reply to comment #15)
> Is the failure repeatable?  (I've seen a build fail, then resubmit, and then 
it
> works... ??)

I'll resubmit the build and report the results.

Same build error again:
http://koji.fedoraproject.org/koji/taskinfo?taskID=177088

Arg, recent qt4 (rawhide) builds inadvertantly omitted the ppc64/64bit patch,
spinning qt4-4.3.2 now with this fix is upstreamed.

* Thu Oct 04 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 4.3.2-1
- qt-4.3.2
- (re)fix ppc64 segfaults, ppc64 fix upstreamed (previous patch was
  inadvertantly not applied) (#246324)

qt4-4.3.2-1.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update qt4'

qt4-4.3.2-1.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.