After hacking around the "scanpci" issue it seems that the "Xorg" Xserver
doesn't build, too:
-- snip --
LD_RUN_PATH=/usr/X11R6/lib cc -o Xorg -xO4 -xbuiltin=%all -xlibmil -xstrconst
-xarch=v8 -Xa -v -zlazyload -zcombreloc -xstrconst -xildoff    
-L../../exports/lib   xkb/xf86KillSrv.o xkb/xf86VT.o xkb/xf86Private.o          
../../programs/Xserver/hw/xfree86/common/xf86Init.o
../../programs/Xserver/hw/xfree86/common/xf86IniExt.o
../../programs/Xserver/hw/xfree86/common/libxf86.a 
../../programs/Xserver/hw/xfree86/parser/libxf86config.a
../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a
../../programs/Xserver/hw/xfree86/loader/libloader.a 
../../programs/Xserver/hw/xfree86/common/libxf86.a dix/libdix.a os/libos.a 
../../lib/font/fontbase.o  ../../lib/font/libfontbase.a Xext/libexts.a
xkb/libxkb.a Xi/libxinput.a  lbx/liblbx.a  ../../lib/lbxutil/liblbxutil.a 
../../programs/Xserver/hw/xfree86/common/libxf86.a  composite/libcomposite.a
damageext/libdamage.a miext/damage/libdamage.a xfixes/libxfixes.a
miext/cw/libcw.a  Xext/libexts.a xkb/libxkb.a Xi/libxinput.a  lbx/liblbx.a 
../../lib/lbxutil/liblbxutil.a  randr/librandr.a render/librender.a
dix/libxpstubs.a mi/libmi.a composite/libcomposite.a damageext/libdamage.a
miext/damage/libdamage.a xfixes/libxfixes.a miext/cw/libcw.a  Xext/libexts.a
xkb/libxkb.a Xi/libxinput.a  lbx/liblbx.a  ../../lib/lbxutil/liblbxutil.a 
randr/librandr.a render/librender.a 
../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a    -lsocket -lnsl -lz
-lm       -lXau -lXdmcp  -ldl  -Wl,-z,lazyload
Undefined                       first referenced
 symbol                             in file
inb                                
../../programs/Xserver/hw/xfree86/common/libxf86.a(xf86Bus.o)
inl                                
../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a(Pci.o)
inw                                
../../programs/Xserver/hw/xfree86/loader/libloader.a(xf86sym.o)
xf86ReadMmio32Le                   
../../programs/Xserver/hw/xfree86/common/libxf86.a(xf86Debug.o)
xf86WriteMmio32Le                  
../../programs/Xserver/hw/xfree86/common/libxf86.a(xf86Debug.o)
xf86ReadMmio16Le                   
../../programs/Xserver/hw/xfree86/common/libxf86.a(xf86Debug.o)
outb                               
../../programs/Xserver/hw/xfree86/common/libxf86.a(xf86Bus.o)
outl                               
../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a(Pci.o)
outw                               
../../programs/Xserver/hw/xfree86/loader/libloader.a(xf86sym.o)
xf86WriteMmio16Le                  
../../programs/Xserver/hw/xfree86/common/libxf86.a(xf86Debug.o)
xf86WriteMmio8                     
../../programs/Xserver/hw/xfree86/common/libxf86.a(xf86Debug.o)
xf86ReadMmio8                      
../../programs/Xserver/hw/xfree86/common/libxf86.a(xf86Debug.o)
ld: fatal: Symbol referencing errors. No output written to Xorg
*** Error code 1
make: Fatal error: Command failed for target `Xorg'
-- snip --

Stuart/Alan:
Can you take the bug and mark it as "assiged" if you are going to work on this
issue, please ?

This isn't a new bug is it?   I don't think you've ever been able to build any
version of Xorg on Solaris SPARC with the Sun compilers, only with gcc, as the
implementations of the inline assembly functions are only available in gcc form.

(I've got a conversion to Sun compiler inlines sitting around that I've been
meaning to putback for a while, but given the inability to run Xorg on Solaris
SPARC, due to the lack of hardware support, it's not been a priority.)

alan.coopersmith@sun.com  wrote:
> This isn't a new bug is it? 

Uhm... if I remember it correctly I didn't had that problem in the past. I just
pulled the source and started a build with "timex nice make World 2>&1 | tee -a
buildlog.log" and the build succeded without problems. This has changed now...
the question is: why ?

> I don't think you've ever been able to build any
> version of Xorg on Solaris SPARC with the Sun compilers

Then either the build of the "Xorg" server was turned-off in the past - or
something broke within the last two months (the problem for verification is that
I have upgraded my compiler to Sun Workshop/Forte 9 (from Workshop/Forte 7) ...
maybe it's just the compiler being on drugs ... ;-( ) ...

Alan/Stuart:
1. Can you run a build with X11R6.8.0 and check whether this builds with Sun
Workshop/Forte, please (my current Ultra5/270MHz/64MB box is far too slow to get
usefull results this night... ;-( ) ?
2. How should we proceed here ? Turn the building of the Xorg server off, try to
fix the problem or somehow wallpaper over it ?

Until just before 6.8.0 release, the SPARC build defaulted to Xsun instead of
Xorg, this was changed to Xorg by the fix for bug 1134.   That bug notes that
Xorg doesn't build with the Sun compilers on Solaris SPARC.

(In reply to comment #5)
> Until just before 6.8.0 release, the SPARC build defaulted to Xsun instead of
> Xorg, this was changed to Xorg by the fix for bug 1134.   That bug notes that
> Xorg doesn't build with the Sun compilers on Solaris SPARC.

Fun... ;-(
Do you have time/resources to get that fixed anytime soon (which would be the
solution I would prefer) or should we simply turn off the building of the Xorg
server for now ?

Created attachment 1565 [details] [review]
[FIXED_X11R68x] Patch to provide Sun compiler compatible versions of SPARC inline assembly routines

This patch provides Sun compiler compatible versions of the inline SPARC
assembly functions needed to build the tree.   With this I can complete a full
build, but since I've never gotten the Xorg server to work on SPARC hardware (I
think there may be problems in the PCI bus code for sparc, and recent
discussion on xfree86@xfree86.org would seem to agree), I can't claim to have
tested this or vouch for it's correctness.   Also note that it's sparcv8plus
code, which means an UltraSPARC/sun4u CPU or better is needed, but since the
only SPARC machines with PCI bus'es also had those CPU's, that seems
reasonable.

[Credit:  Imakefile changes - Alan Coopersmith, assembly code conversion -
Kenjiro Tsuji, both of Sun Microsystems]

Guess I should assign to myself since I'm fixing it in HEAD...

Actually, that should be, "since I already fixed it in HEAD" - this was broken
in 6.8.0, but fixed shortly after that release in HEAD by this putback (which
unfortunately never got a bugzilla bug filed for it):

2004-09-22  Alan Coopersmith  <alan.coopersmith@sun.com>

        * programs/Xserver/hw/xfree86/os-support/sunos/Imakefile:
        * programs/Xserver/hw/xfree86/os-support/sunos/solaris-sparcv8plus.S
        Add support for required assembly inline functions for Sun compilers
        on Solaris/sparc.

So I guess this is just up to deciding whether or not to pull that fix into the
6.8.2 release as well, so I'm reassigning to the 6.8.2 release manager.

Comment on attachment 1565 [details] [review]
[FIXED_X11R68x] Patch to provide Sun compiler compatible versions of SPARC inline assembly routines

Approval for commit into X11R6.8.x stable branch granted in the 2005-01-10 Xorg
release wranglers phone call.

Comment on attachment 1565 [details] [review]
[FIXED_X11R68x] Patch to provide Sun compiler compatible versions of SPARC inline assembly routines

Patch checked-in into X11R6.8.x stable branch:

/cvs/xorg/xc/ChangeLog,v  <--  ChangeLog
new revision: 1.365.2.120; previous revision: 1.365.2.119
cvs commit: Using deprecated info format strings.  Convert your scripts to use
the new argument format and remove '1's from your info file format strings.
/cvs/xorg/xc/config/cf/sun.cf,v  <--  sun.cf
new revision: 1.9.2.1; previous revision: 1.9
cvs commit: Using deprecated info format strings.  Convert your scripts to use
the new argument format and remove '1's from your info file format strings.
/cvs/xorg/xc/programs/Xserver/hw/xfree86/os-support/sunos/Imakefile,v  <-- 
Imakefile
new revision: 1.2.4.2; previous revision: 1.2.4.1
/cvs/xorg/xc/programs/Xserver/hw/xfree86/os-support/sunos/solaris-sparcv8plus.S
,v  <--  solaris-sparcv8plus.S
new revision: 1.1.6.1; previous revision: 1.1
cvs commit: Using deprecated info format strings.  Convert your scripts to use
the new argument format and remove '1's from your info file format strings.
Mailing the commit message to xorg-commit@lists.freedesktop.org...

Patch checked-in into X11R6.8.x stable branch...

... marking bug as FIXED (the problem was fixed in Xorg trunk long long ago).

----

Alan:
Thanks for the patch! :)

.

*** Bug 1394 has been marked as a duplicate of this bug. ***