Bug 245192 - Inventor doesn't build on ppc64
Inventor doesn't build on ppc64
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: Inventor (Show other bugs)
7
All Linux
low Severity low
: ---
: ---
Assigned To: Ralf Corsepius
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FE-ExcludeArch-ppc64/F-ExcludeArch-ppc64 245196
  Show dependency treegraph
 
Reported: 2007-06-21 11:30 EDT by Ralf Corsepius
Modified: 2008-06-16 21:40 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-16 21:40:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ralf Corsepius 2007-06-21 11:30:07 EDT
Build bombs out with a segfault:
...
make[5]: Entering directory
`/builddir/build/BUILD/inventor/doc/man/man3/ivm/draggers'
(cd .. && ../../../../doc/man/ivman/ivman `../../../../doc/man/ivman/makeManDirs
SoCenterballDragger`) > SoCenterballDragger.3iv
(cd .. && ../../../../doc/man/ivman/ivman `../../../../doc/man/ivman/makeManDirs
SoDirectionalLightDragger`) > SoDirectionalLightDragger.3iv
/bin/sh: line 1: 15488 Segmentation fault      ../../../../doc/man/ivman/ivman
`../../../../doc/man/ivman/makeManDirs SoDirectionalLightDragger`
make[5]: *** [SoDirectionalLightDragger.3iv] Error 139

http://koji.fedoraproject.org/koji/getfile?taskID=44693&name=build.log

For now, adding "ExcludeArch: ppc64" to spec
Comment 1 David Woodhouse 2007-06-23 06:13:39 EDT
Ew, the Inventor code is _utterly_ broken. It's casting pointers to int. The
patch below should make it no more broken on PPC64 than it is on x86_64, but
it's still broken. We should stop shipping it on both x86_64 and ppc64 until
it's properly fixed.

inventor/lib/database/include/Inventor/SbPList.h.orig       2007-06-23
05:45:18.000000000 -0400
+++ inventor/lib/database/include/Inventor/SbPList.h    2007-06-23
05:45:41.000000000 -0400
@@ -195,7 +195,7 @@ SoINTERNAL class SbIntList : public SbPL
        { ((SbPList *) this)->insert((void *) (unsigned long) integer, addBefore); }
 
     int &      operator [](int i) const
-#if (_MIPS_SZPTR==64) && (_MIPS_SZINT==32)
+#ifdef __powerpc64__
        // An ugly cast that makes sure that when we cast from void* to
        // int&, we get the rightmost four bytes, rather than the upper
        // bytes.  
Comment 2 Ralf Corsepius 2007-06-24 01:23:11 EDT
(In reply to comment #1)
> Ew, the Inventor code is _utterly_ broken. It's casting pointers to int.
SbPList is an associative map, mapping int->pointers.

The trick they apply is using the least significant bits of an address as key
into a map. This works unless a the least significant bits of an address match
to those of another. Though this isn't a clean approach, in practice, these
occasions rarely apply in Inventor.

> The
> patch below should make it no more broken on PPC64 than it is on x86_64,
Shouldn't this #ifdef distingiush between BIG/LITTLE endian platforms?

> but
> it's still broken.
Right, it's a hack and should be addressed.

> We should stop shipping it on both x86_64 and ppc64 until
> it's properly fixed.
If we'd react such kind of harsh for any such kind of issues, there would not be
much to ship.
Comment 3 David Woodhouse 2007-06-24 15:01:00 EDT
(In reply to comment #2)
> The trick they apply is using the least significant bits of an address as key
> into a map. This works unless a the least significant bits of an address match
> to those of another. Though this isn't a clean approach, in practice, these
> occasions rarely apply in Inventor.

Ick.

> Shouldn't this #ifdef distingiush between BIG/LITTLE endian platforms?

Well yes, but it's a crappy hack just to demonstrate the problem. The correct
response is to _fix_ it.
 
> > We should stop shipping it on both x86_64 and ppc64 until
> > it's properly fixed.
> If we'd react such kind of harsh for any such kind of issues, there would not be
> much to ship.

I very strongly disagree. It takes some effort to write code this bad; we
certainly don't ship much that's this crappy. It should be fixed, or dropped.

Comment 4 David Woodhouse 2008-03-03 07:32:59 EST
You should make a better hash function than  'x & 0xffffffff', but the patch in
comment #1 ought to make ppc64 at least no more broken than x86_64. Does it work?
Comment 5 Ralf Corsepius 2008-03-03 09:12:00 EST
It worked until gcc-4.3.0.

gcc4.3.0's strict-aliasing kills it once again on ppc64.
Comment 6 Ralf Corsepius 2008-03-03 09:12:54 EST
Correction: ... kills it on x86_64 (!)
Comment 7 David Woodhouse 2008-03-03 09:44:37 EST
Methinks it deserved to die :)
Comment 8 Ralf Corsepius 2008-03-03 09:55:51 EST
(In reply to comment #7)
> Methinks it deserved to die :)
If you are referring to the defects in C++'s standards related to aliasing, and
GCC's poor powerpc backend, then I would agree.

Should you be referring to the ppc, I would also agree - Linux on ppc's are a
dying species not worth to be taken care about by a mainstream distro.

Wrt. Inventor, I am working on it ;)

Comment 9 David Woodhouse 2008-03-03 10:26:49 EST
No, I'm referring to the Inventor code.

If you are aware of any problems with the compiler's PowerPC backend which are
causing difficulty for Fedora packages, please make sure they are brought to my
attention. I am not aware of any current issues, and the PowerPC toolchain is
very well maintained.
Comment 10 Ralf Corsepius 2008-03-03 23:54:47 EST
(In reply to comment #9)
> No, I'm referring to the Inventor code.
I expected this answer.

> If you are aware of any problems with the compiler's PowerPC backend which are
> causing difficulty for Fedora packages,
I am not using Fedora on the PowerPC and am not interested wasting time on
catering a dying niche market (Even Apple dumped the PPC)

> PowerPC toolchain is very well maintained.
FWIW: I am aware about dozens of tiny issues with the powerpc-backend in GCC.
Also, implementation-wise, IMO the rs6000 backend in GCC is amongst the worst
maintained code-bases in GCC at all.

Comment 11 Bug Zapper 2008-05-14 09:13:56 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 12 Ralf Corsepius 2008-05-14 10:08:45 EDT
I am really sickened about these triagers producing nothing but spam and noise -
Stop this non-sense, Mr. Stanley.
Comment 13 Bug Zapper 2008-06-16 21:40:39 EDT
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. 
Fedora 7 is no longer maintained, which means that it will not 
receive any further security or bug fix updates. As a result we 
are closing this bug. 

If you can reproduce this bug against a currently maintained version 
of Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.