home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Source Code 1993 July / THE_SOURCE_CODE_CD_ROM.iso / X / mit / server / ddx / x386 / README < prev    next >
Encoding:
Text File  |  1991-07-24  |  7.2 KB  |  184 lines
  1. NOTE: 
  2.  
  3. o  there are warnings from imake, which normally can be ignored
  4.  
  5. o  there are warnings when building the shared-libs which can be ignored
  6.  
  7. o  the server might only be used if all has been installed properly
  8.  
  9. o  the server may produce unpredictable results if it is not run suid-root.
  10.  
  11. o  You must have a installed libdbm.a (This is the renamed PD libgdbm.a). There
  12.    must be /usr/include/ndbm.h installed. Use the same C-compiler for compiling
  13.    libgdbm.a as for X11R4. If working with gcc use -fwritable-strings 
  14.    -fpcc-struct-return.
  15.  
  16. o  /usr/lib/X11/fonts/misc , 75dpi, 100dpi are used, so also if one of these
  17.    directories does not contain any font, there must be a fonts.dir in it.
  18.  
  19. *******************************************************************************
  20.  
  21. SCO:
  22.  
  23. The compiler I used was gcc. The SCO development system contains two
  24. compilers, cc which is an ANSIish Microsoft C 5.1 port and rcc which
  25. is the AT&T pcc-based compiler. I'll discuss the other compiler
  26. attempts below.
  27.  
  28. sin() and cos() seemed to screw up the stack. This seems to be a known
  29. bug with _ftol() that is fixed in the next rev of the DevSys.  In
  30. ./lib/X/XlibInt.c I have redefined _ftol() and it either fixes the
  31. problem or moves it somewhere else.
  32.  
  33. I have been unsuccessful at creating shared libraries. This is a known
  34. problem with the SCO DevSys 3.2, one which is fixed in the SCO DevSys
  35. 3.2v2.0 -- The Sequel.
  36.  
  37. The build was done using 'make BOOTSTRAPCFLAGS=-DSCO -DSYSV386 -DSYSV" World'.
  38.  
  39. Compiler problems --
  40. cc is picky about function prototypes and declarations matching. To avoid
  41. these problems I would specify -DNeedFunctionPrototypes=0 everywhere.
  42.  
  43. cc has resource limitations. I had to simplify one compilicated
  44. expression in ./lib/X/XPutImage.c. It also had a problem with a huge
  45. macro in ./server/ddx/at386/vga/vgaGlyph.c. Splitting the #define up
  46. fixed that.  Identifiers are truncated to 32 characters. This caused
  47. problems with the two macros sz_xMbufGetMultiBufferAttributesRequest
  48. and sz_xMbufGetMultiBufferAttributesReply defined in
  49. ./extensions/include/multibufst.h as well as some interdependent
  50. identifiers elsewhere in ./extensions/include/multibuf.h,
  51. ./extensions/lib/XMultibuf.c and ./extensions/server/multibuf.c. This
  52. also caused the compiler to generate the message
  53.       UNKNOWN ERROR: Contact Microsoft Technical Support
  54.  
  55. In the file ./lib/Xt/Selection.c, cc gave me the error
  56.       static function 'HandleSelectionReplies' not found
  57. This function is first declared static within the scope of another
  58. function and then defined, as static, later in the same file. So I
  59. rearranged some functions so that it is defined before it is invoked.
  60. Then I ran into another problem with another function that was defined
  61. as static, but later it generated an external reference, one which
  62. could never be resolved. By playing musical functions I was able to
  63. find a function ordering that produced a usable object file.
  64.  
  65. The GNU assembly routines for I/O ports did not hang well with cc. SCO
  66. has built-in functions inp, outp and outpw which I used to simulate
  67. inb, outb and outw in place of the GNU inline assembly in
  68. ./server/ddx/at386/compiler.h. These functions are declared intrinsic
  69. using #pragma so the compiler will generate inline in's and out's,
  70. i.e. no function calls.
  71.  
  72. I have not tried rcc on this code and I don't think I will. It does not
  73. produce very good code.
  74.  
  75. That leaves us with gcc, which is capable of compiling all the
  76. sources. Be careful to specify the -fpcc-struct-return switch or
  77. else you'll produce incompatible code with SCO's libdbm.a.
  78.  
  79. I've seen one instances where the three compilers produce mutually
  80. incompatible code.
  81.  
  82. ./server/ddx/mfb/mfb.h defines the struct mfbPrivGC which contains 3
  83. unsigned char followed by two unsigned bitfields, each one bit,
  84. followed by a pointer and other stuff.
  85.  
  86.       struct bad_news {
  87.           unsigned char a;
  88.           unsigned char b;
  89.           unsigned char c;
  90.           unsigned      x:1;
  91.           unsigned      y:1;
  92.           char *        p;
  93.       };
  94.  
  95. offsets generated          cc  rcc gcc
  96.         unsigned char a    0   0   0
  97.         unsigned char b    1   1   1
  98.         unsigned char c    2   2   2
  99.         unsigned      x:1  4   3   3
  100.         unsigned      y:1  4   3   3
  101.         char *        p    8   4   4
  102.  
  103. Not a good situation when you compile different files with different
  104. compilers.
  105.  
  106. 1.1 has additional TCP/IP support for System V/386 Unixes. Each vendor
  107. has decided to support the Berkeley socket interface each in their own
  108. twisted ways. Differences not only crop up with the kernel interface
  109. but also which include files contain the appropriate definitions.
  110.  
  111. The SCO kernel interface is the non-STREAMS driver /dev/socksys. There
  112. is a convenient library libsocket.a with all the Berkeley networking
  113. and utility functions. Problem is it is not a STREAMS driver and
  114. it cannot handle the I_NREAD ioctl. This driver will accept FIONREAD.
  115. In ./mit/lib/X/Xlibos.h, BytesReadable is defined in terms of one of
  116. these two ioctls. Which one should SCO use? The answer is both. When
  117. you want BytesReadable from a LOCALCONN you need to use I_NREAD. From
  118. a TCPCONN you use FIONREAD. So the #define BytesReadable is replaced
  119. by a function in ./mit/lib/X/XlibInt.c, which will try I_NREAD and
  120. then FIONREAD if that fails.
  121.  
  122. With the new TCP/IP support I have found yet another problem, this
  123. time with the TCP/IP dev sys. I have an early version 1.0.0. The
  124. function inet_addr() seems to be corrupting some of the non-disposable
  125. registers.  However I couldn't reproduce this behavior in a standalone
  126. program.  For this I went ahead and replaced inet_addr() in libsocket.a
  127. using 'ar' with my own simple-minded function.
  128.  
  129. unsigned long inet_addr(name)
  130. char *name;
  131. {
  132.     unsigned d0, d1, d2, d3;
  133.  
  134.     if (sscanf(name, "%d.%d.%d.%d", &d3, &d2, &d1, &d0) != 4)
  135.     return 0xffffffff;
  136.  
  137.     return (d0<<24)|(d1<<16)|(d2<<8)|(d3);
  138. }
  139.  
  140. More incompatibilties. Thomas has beefed up his select() via poll()
  141. emulation routine, ./mit/server/ddx/at386/bsdemul/select.c. POLLPRI is
  142. added to the events mask of all the fd's. For whatever reason this
  143. causes /dev/tty and /dev/tty[12]a (serial port) to induce poll to fail
  144. with EINVAL. The STREAMS connection /dev/ptmx and the TCP connection
  145. /dev/socksys don't mind as much.
  146.  
  147. February 24, 1991
  148. -----------------
  149.  
  150. Jim Kelly
  151. Microsoft Corporation
  152. uunet!microsoft!jimke
  153.  
  154.  
  155. *******************************************************************************
  156.  
  157. Ok floks, it really works !!!
  158.  
  159. (PLEASE EVERYBODY WHO DEVELOPES X-APPLICATIONS SHOULD READ THIS !!!)
  160.  
  161.  
  162. 1) Building X386
  163.  
  164. The only point is that stock AT&T cc may fail in many places. But on the other
  165. hand gcc doesn't understand '-z nodefs'. Thus we should use here cc and add
  166. this flag to gcc later. BTW throught all the places is assumed that there
  167. exist dbm.h & ndbm.h in /usr/include. If not, make links from /usr/ucbinclude.
  168.  
  169.  
  170. 2) Library paths
  171.  
  172. All libs are now in /usr/X386/lib. Thus you have to add this directory to
  173. you LD_LIBRARY_PATH. But just setting LD_LIBRARY_PATH fails for suid-clients.
  174. For these you have to specify LD_RUN_PATH during linking. Thus all you have
  175. to do is:
  176.  
  177.       1) Normal 'make World'
  178.       2) 'export LD_RUN_PATH=/usr/X386/lib'
  179.          delete mit/clients/xterm/xterm & mit/clients/xload/xload and
  180.          relink them again.
  181.       3) Continue with 'make install'
  182.  
  183.  
  184.