Bug 2386 - xrx does not build on Mac OS X/*BSD/AIX in X11R6.8.x stable branch
Summary: xrx does not build on Mac OS X/*BSD/AIX in X11R6.8.x stable branch
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: App/other (show other bugs)
Version: 6.8.2
Hardware: PowerPC Mac OS X (All)
: high blocker
Assignee: Roland Mainz
QA Contact:
URL:
Whiteboard:
Keywords:
: 2423 (view as bug list)
Depends on: 2398
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-26 16:38 UTC by Torrey T. Lyons
Modified: 2007-01-23 20:00 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments
[FIXED_X11R68x] Proposed fix for X11R6.8.x stable branch (3.55 KB, patch)
2005-01-27 16:58 UTC, Roland Mainz
roland.mainz: 6.8-branch+
Details | Splinter Review

Description Torrey T. Lyons 2005-01-26 16:38:58 UTC
When building xrx from 6.8.2RC3 on Mac OS X one gets the error:

/usr/bin/cc -c -Os  -Wall -Wpointer-arith -no-cpp-precomp -fno-common  -I. -I../plugin -I../plugin/
include -I../rx   -I../../.. -I../../../exports/include   -D__powerpc__ -D__DARWIN__                                 
-DNO_ALLOCA -DCSRG_BASED      -DNETSCAPE_PLUGIN -DXP_UNIX -DNO_STARTING_STATE 
-DBSD44SOCKETS     -dynamic XnestDis.c
XnestDis.c: In function `IsDisplayNumFree':
XnestDis.c:57: error: storage size of `sbuf' isn't known
XnestDis.c:62: warning: implicit declaration of function `stat'
XnestDis.c:57: warning: unused variable `sbuf'
make: *** [XnestDis.o] Error 1

This is because the stat struct is defined in sys/stat.h, which is not pulled in. Adding the following 
patch fixes this and causes xrx to build correctly:

RCS file: /cvs/xorg/xc/programs/xrx/xnest-plugin/XnestDis.c,v
retrieving revision 1.2.4.1
diff -u -d -b -w -r1.2.4.1 XnestDis.c
--- XnestDis.c  24 Jan 2005 05:01:54 -0000      1.2.4.1
+++ XnestDis.c  27 Jan 2005 00:36:45 -0000
@@ -29,6 +29,7 @@
 /* $XFree86$ */
 
 #include "RxPlugin.h"
+#include <sys/stat.h>
 
 /***********************************************************************
  * Utility functions and global variable to manage display numbers

However, this is probably not platform independent. What is a good way to generalize this fix?
Comment 1 Roland Mainz 2005-01-26 16:40:34 UTC
Taking bug myself...
Comment 2 Roland Mainz 2005-01-26 16:42:20 UTC
Torrey:
1. What about putting the #include into a "#ifdef IS_MACOSX ... #endif"-block -
would that work ?
2. Does the problem occur with Xorg trunk, too ?
Comment 3 Torrey T. Lyons 2005-01-26 17:18:39 UTC
(In reply to comment #2)
1. Yes, we can just wrap it as follows if that is best:

#ifdef __DARWIN__
#include <sys/stat.h>
#endif

We use __DARWIN__ in the X.Org tree to specify Darwin-based OSes. I'm surprised no other BSD's have 
this issue.

2. Miraculously the top of the tree has #include <sys/stat.h> already I just discovered. Perhaps that is 
correct in general and should just be put into the 6.8 branch.
Comment 4 Donnie Berkholz 2005-01-26 23:46:10 UTC
This also hits FreeBSD, see
http://tinderbox.anholt.net/tinderbox3/showlog.pl?machine_id=4&logfile=20050126202533.log&page=40
Comment 5 Matthieu Herrb 2005-01-27 00:12:48 UTC
OpenBSD is affected too. 
I guess only Linux defines the stat struct inside <stdio.h> :(
Comment 6 Roland Mainz 2005-01-27 16:58:50 UTC
Created attachment 1766 [details] [review]
[FIXED_X11R68x] Proposed fix for X11R6.8.x stable branch

The patch simply resyncs the X11R6.8.x stable branch with 2005-01-28-trunk to
include the MacOSX/*BSD/AIX fixes from CVS HEAD.
Comment 7 Roland Mainz 2005-01-27 17:00:24 UTC
Torrey/Donnie:
Can you verify that the patch fixes your problem, please ?
Comment 8 Donnie Berkholz 2005-01-27 19:30:06 UTC
Keep an eye on the anholt-i386-6_8 box at
http://tinderbox.anholt.net/tinderbox3/showbuilds.pl?tree=XMonolithic
Comment 9 Torrey T. Lyons 2005-01-28 14:56:19 UTC
The proposed patch fixes the problem for Mac OS X.
Comment 10 Donnie Berkholz 2005-01-28 14:58:07 UTC
Oops, sorry -- didn't realize it was proposed and not committed. Once it gets
committed, then check the tinderbox. It's not mine so I can't do anything about it.
Comment 11 Daniel Stone 2005-01-29 17:53:38 UTC
It seems very much to me xrx has not received sufficient 'soak time' and that
the technology is not quite mature enough to be in the branch; I would not
expect builds to break this drastically between release candidates, which are
supposedly only receiving known-good bugfixes.  Were we unable to test this
plugin even in HEAD first for some reason?  I would argue that this plugin
should be removed from the branch until it has been shown to at least build on a
decent percentage of architectures and platforms outside of Linux/x86, which it
has been proven to not do thus far.  I generally take snapshots from the branch
and push them to my customers as part of our (testing) packages, but I may have
to review this practice if the branch is constantly used as a place for testing
new code rather than a platform for pushing stable, well-tested fixes that have
soaked in HEAD.
Comment 12 Roland Mainz 2005-01-30 13:54:43 UTC
*** Bug 2423 has been marked as a duplicate of this bug. ***
Comment 13 Roland Mainz 2005-01-31 08:01:59 UTC
(In reply to comment #11)
> It seems very much to me xrx has not received sufficient 'soak time' and that
> the technology is not quite mature enough to be in the branch; I would not
> expect builds to break this drastically between release candidates, which are
> supposedly only receiving known-good bugfixes.

Daniel:
Did you actually read the description of the proposed patch and _realise_ that
these patches are build bustage fixes from "trunk" ? Unfortunately the bustage
fixes were not part of the original XRX patch - but that also applies to the
build bustage caused by the Mesa update, the brasillian patch from Debian and
other features commited to the release branch...
Comment 14 Roland Mainz 2005-01-31 08:17:50 UTC
Comment on attachment 1766 [details] [review]
[FIXED_X11R68x] Proposed fix for X11R6.8.x stable branch

(Forgot to request approval for this, sorry... ;-/)
Comment 15 Daniel Stone 2005-01-31 15:46:50 UTC
Roland: Sorry, I thought the xrx .c file was lacking an include somewhere; I
didn't actually realise that this was caused by the Brazilian locale patches. 
My bad.
Comment 16 Roland Mainz 2005-02-01 02:58:30 UTC
Comment on attachment 1766 [details] [review]
[FIXED_X11R68x] Proposed fix for X11R6.8.x stable branch

Patch approved in the 2005-01-31 Xorg release-wranglers phone call for commit
into the X11R6.8.x stable branch.
Comment 17 Roland Mainz 2005-02-01 03:08:09 UTC
Comment on attachment 1766 [details] [review]
[FIXED_X11R68x] Proposed fix for X11R6.8.x stable branch

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

/cvs/xorg/xc/ChangeLog,v  <--  xc/ChangeLog
new revision: 1.365.2.142; previous revision: 1.365.2.141
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/xrx/plugin/include/npapi.h,v  <-- 
xc/programs/xrx/plugin/include/npapi.h
new revision: 1.2.4.1; previous revision: 1.2
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/xrx/xnest-plugin/XnestDis.c,v  <-- 
xc/programs/xrx/xnest-plugin/XnestDis.c
new revision: 1.2.4.2; previous revision: 1.2.4.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...
Comment 18 Roland Mainz 2005-02-01 03:08:49 UTC
Patch checked-in...

... marking bug as FIXED (please reopen if there are any build issues left).
Comment 19 Roland Mainz 2005-02-01 08:28:48 UTC
(In reply to comment #4)
> This also hits FreeBSD, see
>
http://tinderbox.anholt.net/tinderbox3/showlog.pl?machine_id=4&logfile=20050126202533.log&page=40

The tinderbox ("anholt-i386-6_8") switched to "GREEN" again few hours ago...


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.