| Summary: | Build failure in X11R6.8.x stable branch's "Xorg" Xserver and "scanpci" tool | ||||||
|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Roland Mainz <roland.mainz> | ||||
| Component: | * Other | Assignee: | Roland Mainz <roland.mainz> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | blocker | ||||||
| Priority: | highest | CC: | aaronw, alan.coopersmith, eich, stuart.kreitman | ||||
| Version: | 6.8.2 | ||||||
| Hardware: | SPARC | ||||||
| OS: | Solaris | ||||||
| Whiteboard: | |||||||
| i915 platform: | i915 features: | ||||||
| Attachments: |
|
||||||
|
Description
Roland Mainz
2004-12-17 00:26:39 UTC
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. *** |
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.