Bug 303 - PowerPC64 changes break makedepend/imake on non-PPC64 platforms
Summary: PowerPC64 changes break makedepend/imake on non-PPC64 platforms
Alias: None
Product: xorg
Classification: Unclassified
Component: Build/Monolithic (show other bugs)
Version: unspecified
Hardware: x86 (IA32) All
: high normal
Assignee: Mike A. Harris
QA Contact:
Depends on:
Blocks: 351
  Show dependency treegraph
Reported: 2004-03-12 17:08 UTC by Alan Coopersmith
Modified: 2011-10-15 15:46 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:

Updated PPC64 support patch (8.13 KB, patch)
2004-04-06 22:59 UTC, Mike A. Harris
no flags Details | Splinter Review
PPC64 support patch, updated to work with final X11R6.7.0 release (8.13 KB, patch)
2004-04-08 06:48 UTC, Mike A. Harris
no flags Details | Splinter Review

Description Alan Coopersmith 2004-03-12 17:08:29 UTC
Building the XORG-RELEASE-1 branch on an x86 box today, I noticed many strange
errors in my build logs, such as:

../../../config/makedepend/makedepend: warning:  cfbgc.c (reading
../../../programs/Xserver/include/compiler.h), line 1462: #    error - Non-gcc
PowerPC and !PowerMAXOS ???

Looking at xc/config/imake/imakemdep.h where it defines the preprocessor symbols
to be used in makedepend and imake on each platform, it appears the PPC64 changes
were added incorrectly.

Specifically these sections:
# ifdef __powerpc__
#  ifdef __powerpc64__
#  endif
# else
# endif


# ifdef __powerpc__
#  ifdef __powerpc64__
        {"__powerpc64__", "1"},
#  endif
# else
        {"__powerpc__", "1"},
# endif

Both the #endif and #else lines were added after the PPC64 additions, but only
one of them should have been, as the current result is
On PowerPC64: define __powerpc64__
On PowerPC that is not-PowerPC64: define nothing
On everything but PowerPC: define __powerpc__

Either the #else or the #endif need to be removed from both sections (depending
on whether __powerpc__ should be defined on both PPC & PPC64 or just PPC).
Comment 1 Mike A. Harris 2004-03-13 10:07:51 UTC
Indeed, something looks awry there.  Just as a datapoint what OS/version
and compiler/version are you using?  The error you describe doesn't occur
here, but from the look of the code it should.

I'll look more closely into this on Monday.

Thanks for spotting this Alan.
Comment 2 Alan Coopersmith 2004-03-13 10:42:12 UTC
I saw this on Solaris 9 x86 with the Sun compilers.
Comment 3 Egbert Eich 2004-03-15 05:51:46 UTC
This patch shouldn't be in the RELEASE branch anyway. Please fix and apply it to
the CURRENT branch.
Comment 4 Egbert Eich 2004-03-24 08:48:51 UTC
Assign it to the next release.
Comment 5 Mike A. Harris 2004-04-06 22:59:53 UTC
Created attachment 175 [details] [review]
Updated PPC64 support patch

This updated patch includes the support which was previously committed by me
to the XORG-RELEASE-1 branch and later reverted, plus fixes for the issues
reported by Alan Coopersmith in this bug report, and an additional fix for
an issue we discovered in routine testing, where BIG_ENDIAN wasn't getting
properly defined on PPC64 with the X.org release.  The patch is also updated
to apply cleanly to the current CVS as of a couple of minutes ago, and should
apply without fuzz, etc.

I'm posting it here first for review by Alan and Egbert, and would prefer to
get at least 2 people to sign off on it before I commit it to XORG-CURRENT
in CVS.

Any build/runtime testing others would be willing to do would also be
appreciated, in particular on non-Linux systems, and with non GNU compilers,
as that improves the chances of problems getting detected.

If there are any further issues with the patch, please let me know and I will
try to address them and provide an updated patch once it can be tested.

Thanks in advance.
Comment 6 Mike A. Harris 2004-04-08 06:48:35 UTC
Created attachment 183 [details] [review]
PPC64 support patch, updated to work with final X11R6.7.0 release

This patch, has been updated to work with final X11R6.7.0 release.  It is
identical, except changed to patch xorg.cf instead of xfree86.cf.
Comment 7 Alan Coopersmith 2004-04-18 04:19:03 UTC
The latest patch looks fine to me, and I don't see any of the previous errors
when I apply to a checkout from the current tree and build it on the Solaris x86
system that previously hit errors.  I don't have a PPC or PPC64 box to confirm it 
does the right thing there - but since it seems to not break existing platforms, I 
think it should be safe to check in now.
Comment 8 Mike A. Harris 2004-04-20 11:13:37 UTC
Shall I check it into the trunk now (HEAD), or is some other branch more

Just want to confirm first.
Comment 9 Kevin E. Martin 2004-08-02 18:45:54 UTC
Has anyone tested this patch against the current trunk?  Does anyone have a
PPC64 system to test?

The patch looks innocuous enough but it should be tested before checking into
the trunk.
Comment 10 Mike A. Harris 2004-08-06 23:13:18 UTC
I'm currently build testing ppc64 in FC3 devel builds.  s390 is failing, so
not sure if ppc64 builds clean yet or not.  Will know over the weekend.  This
patch is applied in our rpms, and should be harmless to apply IMHO unless
someone knows of issues on non-Linux systems, but nothing has been reported
to date that I'm aware.

Once I get a successful xorg ppc64 build, I'll update the status here.
Comment 11 Kevin E. Martin 2004-08-09 15:49:05 UTC
Any updates on the build status with the current CVS head?
Comment 12 Mike A. Harris 2004-08-09 23:50:40 UTC
The current 6.7.99.x src.rpm builds on PPC64 just fine now.  Any of the
build problems I encountered while packaging this for PPC64 were minor rpm
packaging related issues.  There are no PPC64 or other arch/OS related issues
that I'm aware of currently with this patch applied to the Xorg sources.  I
believe it should be safe to apply.

Comment 13 Kevin E. Martin 2004-08-11 14:15:04 UTC
Patch checked in.  Closing.
Comment 14 Kristian Høgsberg 2004-08-12 07:38:06 UTC
Changed xorg.cf to define XorgServer instead of XF86Server.  From mharris.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.