HDTenEightyP/NetNews huggingface dataset:
From: alberto@proa.es (Alberto Poblacion)
Newsgroups: biz.sco.opendesktop,biz.sco.general
Subject: Re: SLIP Drivers
Summary: Not SLIP but tty drivers. Use fas instead.
Keywords: slip,unix,sco,TCP/IP,fas
Date: 19 Nov 92 17:30:58 GMT
Reply-To: alberto@proa.es (Alberto Poblacion)
Followup-To: biz.sco.opendesktop
Organization: PROA - Compugraf,S.A. MADRID Spain

In article <1992Nov18.005400.9013@blkbox> mknewman@blkbox (Marc Kraker Newman) writes:
>Can anyone tell me why the SCO SLIP drivers in my ODT 1.1g do not support
>flow control?  I am using it with a V32/V42bis modem, which can handle more
>than 9600 baud, but when I try 19200 or 38400, the modem is signaling via CTS 
>for the system to slow down, but the system just keeps sending data

      It's not a problem of the SLIP drivers, but the tty drivers. SLIP
just goes through the tty device that you selected during instalation.
The SCO tty drivers do not support the usual handshake used by high speed
modems (in version 3.2.2 or ODT 1.x). You may install the "fas" drivers
instead of the SCO serial drivers. FAS supports a lot of options, including
a handshake mode which handles RTS/CTS. I have never tried SLIP over FAS,
but the TCP/IP manuals assert that it works on any device that has a
standard tty interface.


-- 
Alberto Poblacion
E-mail: alberto@proa.es
Newsgroups: biz.sco.opendesktop,comp.unix.sysv386,comp.unix.programmer
From: dan@dribble.c-mols.siu.edu (Dan Ellison)
Subject: Problems with SCO DEVSYS 3.2.4d include files - help?
Organization: Southern Illinois University - Carbondale, IL (SIU-C)
Distribution: na
Date: Sun, 15 Nov 1992 17:06:38 GMT

I am evaluating the SCO devsys version 3.2.4d here and am experiencing
some real problems with the include files not defining some pretty
standard things (like sys/types.h and sys/signal.h.)

Specifically, I am trying to build gcc-2.3.1.  I have built it without
any problems using the 3.2.0 devsys package.  However, when I try it
under 3.2.4d, I get through the first pass fine, but wehn I start
trying to compile with the xgcc program I start running into numerous
errors having to do with the include files.  IT seems that if you
define _POSIX_SOURCE you get around some of the problwms but create 
others.  The same is true for _XOPEN_SOURCE.  Fix one, create more.

Has anyone succeeded in building gcc2.3.1 with this version of the devsys
package?  I'm starting to feel like I am the victim of some cruel SCO
joke or something.

I should note that most applications I have attempted to install using
the standrad cc compiler have compiled clean.  Must be some fundamental
definition or library that is or is not being used.  Any help greatly
appreciated and thanks.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Dan Ellison, Network Spec 	  -    	Computing Affairs, SIU-C 	| 
| Southern Illinois University 	  - 	Carbondale, IL 62901            |   
| FAX:      (618) 453-3459        -   	PHONE:    (618) 453-6149 	|     
Newsgroups: biz.sco.opendesktop
From: mknewman@blkbox (Marc Kraker Newman)
Subject: Re: Talk command
Organization: The Black Box, PO Box 591822 Houston, TX 77259-1822 
Date: Thu, 19 Nov 1992 13:08:03 GMT

kevin@shady.UUCP (Kevin Smith) writes:

>In article <1992Nov13.132205.17088@blkbox> mknewman@blkbox (Marc Kraker Newman) writes:
>>Has anyone had any luck using the talk command under ODT 1.1 or 2.0 ?  I have
>>only been able to get it to work on non-xterm sessions.  Logging on as root
>>it works, but in an xterm window it tells me 'You don't exist.  Go away.'.

>You need to run xterm with the '+ut' flag or 'xterm*utmpInhibit: false'
>resource.  This will cause xterm to write a /etc/utmp record for the
>pseudo tty... Then you will exist.
>-- 

Thanks, Kevin.  That did allow me to use the talk command, but now, after I
'talk' to someone, there are a whole mess of talkd daemons being left behind.

Is there a fix to this?

Marc

-- 
Marc K. Newman (N5SLG)			Is UNIX pronounced 
mknewman@blkbox.com 			"UNIQUES" or
PO BOX 591822				"EUNICHS"?
Houston, Texas 77259-1822
Newsgroups: biz.sco.opendesktop
From: shaman@cix.compulink.co.uk (Leo Smith)
Subject: Re: BOOTP implementation on SCO UNIX
Reply-To: shaman@cix.compulink.co.uk
Date: Thu, 19 Nov 1992 08:56:00 +0000

If you are looking for a SCO bootpd, a comapny called schasiepen GMBH
in Germany had one for the ealier SCO unix, as part of their support
suite of TCP/IP boot roms.

FTP software (info@ftp.com) in Boston used to re-sell these ROMs (and
may still do so). It may be worth trying them to see if you can pick
up the code. I know they have bootpd source (BSD tho I expect). I did
get a bootpd going on SCO in a previous incarnation, so its not hard.

It may be valuable to cross post to the TCP/IP groups (if you haven't
done so already)

Sorry about lack of original: The equipment I am using here is
arcane.

Leo
Xref: sparky biz.sco.opendesktop:752 biz.sco.general:4191 comp.unix.xenix.sco:3345
From: jxv3790@hertz.njit.edu (Jake Vogelaar)
Newsgroups: biz.sco.opendesktop,biz.sco.general,comp.unix.xenix.sco
Subject: Re: XView for SCO Unix?
Date: 17 Nov 92 21:51:24 GMT
Organization: New Jersey Institute of Technology, Newark, N.J.

In article <1ebcnqINNg2f@life.ai.mit.edu> gillett@rice-chex.ai.mit.edu (Walter E. Gillett) writes:
>Hi, Folks
>    I'm about to port an application from SunOS to SCO Unix.  This application
>uses the XView X-Windows library.  Does anyone know of a version of an XView
>port to SCO Unix?  I'm interested in both XView2 and XView3.

How about Xenix anybody?  Has anyone attempted XView2 for X386?  Is it
possible to port only the OL window manager?

jake
-- 
/////////////////////////////////////////////////////////////////////////
Jake Vogelaar, jxv3790@hertz.njit.edu
Computer Vision R&D, Warner-Lambert Manufacturing Development Laboratory
New Jersey Institute of Technology
Newsgroups: biz.sco.opendesktop
From: mknewman@blkbox (Marc Kraker Newman)
Subject: Re: SLIP Drivers
Organization: The Black Box, PO Box 591822 Houston, TX 77259-1822 
Date: Mon, 23 Nov 1992 02:23:04 GMT
Keywords: slip,unix,sco,TCP/IP,fas

alberto@proa.es (Alberto Poblacion) writes:

>In article <1992Nov18.005400.9013@blkbox> mknewman@blkbox (Marc Kraker Newman) writes:
>>Can anyone tell me why the SCO SLIP drivers in my ODT 1.1g do not support
>>flow control?  I am using it with a V32/V42bis modem, which can handle more
>>than 9600 baud, but when I try 19200 or 38400, the modem is signaling via CTS 
>>for the system to slow down, but the system just keeps sending data

>      It's not a problem of the SLIP drivers, but the tty drivers. SLIP
>just goes through the tty device that you selected during instalation.
>The SCO tty drivers do not support the usual handshake used by high speed
>modems (in version 3.2.2 or ODT 1.x). You may install the "fas" drivers
>instead of the SCO serial drivers. FAS supports a lot of options, including
>a handshake mode which handles RTS/CTS. I have never tried SLIP over FAS,
>but the TCP/IP manuals assert that it works on any device that has a
>standard tty interface.

This is incorrect!  I got several answers to my first message, and some
suggested that I do a 'stty rtsflow ctsflow </dev/ttyXX' AFTER I started up
slip.  THIS FIXED IT!  What happens is that slip turns rtsflow/ctsflow OFF
no matter WHAT you have it set to before starting.  This means the port should
be the CAPITAL letter port (tty1A) not the lower case version, so flow control
can work.

I just added the stty after the slattach in my startup, and now it works.

Marc
 
-- 
Marc K. Newman (N5SLG)			Is UNIX pronounced 
mknewman@blkbox.com 			"UNIQUES" or
PO BOX 591822				"EUNICHS"?
Houston, Texas 77259-1822
Newsgroups: biz.sco.opendesktop
From: garyh@sco.COM (< Gary H >)
Subject: Re: Use gcc with X in SCO
Organization: The Santa Cruz Operation, Inc.
Date: Thu, 19 Nov 1992 01:58:43 GMT
Keywords: gcc 2.2.2, X, ODT


In article <BrEzxK.C46@zorch.SF-Bay.ORG> pchi@zorch.SF-Bay.ORG (Eric Chi) writes:
!Hi,
!	I ported gcc 2.2.2 to SCO ODT 1.0 and tried to compile a
!simple X program but failed. The compiler complains a lot about some
!X ( Xlib) include files. Does any one know how to solve this?
!Thanks.
!
!Eric.

You'll need to get the X include files from MIT.  If the program is Motif
based, you'll need the include files from OSF.  All the include files
(X, Xt, Xm, extensions, Mrm, and uil) are included in the ODT Development
System.

You can't simply compile X programs with gcc alone.  You'll also need the
X libraries (as well as the header files).  These libraries are also
part of the ODT Dev Sys.

Gary
-- 
|^^^^^^|            _Yo_Man_____________________________
|      |          /            garyh@sco.com             \
|  _  _|        /             uunet!sco!garyh              \
| (o)(o)      /             425  Encinal Street              \
@      _)   /          Santa Cruz, California  95061          |
 | ,___|   /   W: [408] 457-0195 x7765 / Fax: [408] 429-1887 /
 |   /     \_______________________________________________/
/____\            The Santa Cruz Operation (SCO), Inc.
Newsgroups: biz.sco.opendesktop,comp.unix.sysv386,comp.unix.programmer
From: rac@sherpa.UUCP (Roger Cornelius)
Subject: Re: Problems with SCO DEVSYS 3.2.4d include files - help?
Organization: none
Distribution: na
Date: Mon, 16 Nov 1992 02:02:36 GMT

I responded via email but thought others might be interested also.

In article <dan.721847198@dribble>, dan@dribble.c-mols.siu.edu (Dan Ellison) writes:
> I am evaluating the SCO devsys version 3.2.4d here and am experiencing
> some real problems with the include files not defining some pretty
> standard things (like sys/types.h and sys/signal.h.)
> 
> Specifically, I am trying to build gcc-2.3.1.  I have built it without
> any problems using the 3.2.0 devsys package.  However, when I try it
> under 3.2.4d, I get through the first pass fine, but wehn I start
> trying to compile with the xgcc program I start running into numerous
> errors having to do with the include files.  IT seems that if you
> define _POSIX_SOURCE you get around some of the problwms but create 
> others.  The same is true for _XOPEN_SOURCE.  Fix one, create more.

The problem is not really a header file one but a preprocessor one.
The SCO supplied preprocessor treats undefined tokens the same as
ones defined as 0.  Many of the 3.2v4 header files depend on this
fact.  The gnu preprocessor treats undefined tokens as different from
ones defined as zero.  The reason the first pass of the gcc build
works is because the SCO compiler and preprocessor are used.

The solution is to use the -traditional-cpp flag to gcc, even when
building gcc itself.

> Has anyone succeeded in building gcc2.3.1 with this version of the devsys
> package?

Yes.

-- 
Roger Cornelius        sherpa!rac@uunet.uu.net       ...!uunet!sherpa!rac
Newsgroups: biz.sco.opendesktop,biz.sco.general
From: mknewman@blkbox (Marc Kraker Newman)
Subject: SLIP Drivers
Organization: The Black Box, PO Box 591822 Houston, TX 77259-1822 
Date: Wed, 18 Nov 1992 00:54:00 GMT
Summary: Flow control does not work on SCO slip drivers
Keywords: slip,unix,sco,TCP/IP

Can anyone tell me why the SCO SLIP drivers in my ODT 1.1g do not support
flow control?  I am using it with a V32/V42bis modem, which can handle more
than 9600 baud, but when I try 19200 or 38400, the modem is signaling via CTS 
for the system to slow down, but the system just keeps sending data, causing
lost packets, and eventual shutdown of the slip connection.

I have seen several SLIP drivers in the public domain.  Has anyone gotten any
of these going under SCO or ODT?

Thanks in advance.


-- 
Marc K. Newman (N5SLG)			Is UNIX pronounced 
mknewman@blkbox.com 			"UNIQUES" or
PO BOX 591822				"EUNICHS"?
Houston, Texas 77259-1822
Newsgroups: biz.sco.opendesktop
Subject: Programming and inetd (ADMN)
From: karh@pa621a.inland.com
Date: 18 Nov 92 10:51:07 CDT
Organization: Inland Steel Company, East Chicago, IN
Nntp-Posting-User: nason

Help me,

I'm trying to make an program that will be launched by inetd. With help from
the documentation, I've setup the service and added the entry to inetd.conf. 
However, my program doesn't seem to recieve any information from the net.

      Socket Type:      dgram
      Protocol:         udp
      Wait/Nowait:      nowait
      User ID:          root

According to the inetd man page :

         ...
         When there is data waiting on a datagram socket,  inetd
         forks,  dups, and execs the appropriate server, passing
         it any server program arguments; unlike  a  connection-
         based  server,  a  datagram  server  has  I/O to stdin,
         stdout, and stderr done to the original socket.  If the
         datagram socket is marked as wait (which corresponds to
         an entry in inetd's configuration  file),  the  invoked
         server  must process the message before inetd considers
         the socket  available  for  new  connections.
         ...
         
So, I think that means when I do my recvfrom, I should use the sdtin IO handle 
0 (zero).  For example:

/* Include IO and Socket Headers */

int main (argc, argv)
      int    argc;
      char** argv;
{
      int len;
      int count;

      char buffer [1024];

      struct sockaddr_in sin;

      len = sizeof (sin);
      count = recvfrom (0, buffer, sizeof (buffer), 0, &sin, &len);

      /* Open file and write buffer into it */

      exit (1);
}


This doesn't seem to work... What am I missing???

Thanks in advance. (Summary posted if enough response)

Bill
-----------------------------------------------------------------------------
Opinions expressed    | William D. Karh           |       InterNet:
are not those of my   | Dept. Process Automation  |  karh@pa881a.inland.com
employer...           | Inland Steel FPC          |

Newsgroups: biz.sco.opendesktop
From: dlucy@sandr.COM (Doug Lucy)
Subject: Slow login and u386mon
Organization: S&R Software, Incorporated
Distribution: usa
Date: Sat, 21 Nov 1992 01:09:01 GMT

Our SCO ODT 1.1 Sys V/386 3.2.2 installation and become slower and
slower during the actual login-to-shell-prompt. Actual commands run
from the shell perform adequately, but the time from the return at the
end of entering the password to actual shell prompt is intolerable at
about 45 to 60 seconds.

I've ftp'ed and compiled u386mon which makes nice displays and is
showing 100% CPU utilization during the login. However, the docs are
sparse and I don't see any danger-sign red in the main table.

Anybody know of more detailed docs or where to look for the source of
the problem?  Thanks much.

-- 
| Doug Lucy             | Although I am responsible for my  |
| S&R Software, Inc     | opinions, I'm not responsible for |
| dlucy@sandr.COM       | my poor spelling.                 |
Newsgroups: biz.sco.opendesktop,comp.unix.sysv386,comp.unix.programmer
From: rac@sherpa.UUCP (Roger Cornelius)
Subject: Re: Problems with SCO DEVSYS 3.2.4d include files - help?
Organization: none
Distribution: na
Date: Tue, 17 Nov 1992 19:58:05 GMT

In article <BxsDoD.CuG@sherpa.UUCP>, I wrote:
> 
> The problem is not really a header file one but a preprocessor one.
> The SCO supplied preprocessor treats undefined tokens the same as
> ones defined as 0.  Many of the 3.2v4 header files depend on this
> fact.  The gnu preprocessor treats undefined tokens as different from
> ones defined as zero.  The reason the first pass of the gcc build
> works is because the SCO compiler and preprocessor are used.

This isn't quite correct.  My comments about the SCO and GNU
preprocessors treating undefined tokens differently is wrong.

The GNU preprocessor, by default, defines __STDC__ to 1.  If the
-traditional-cpp flag is given to gcc (or -traditional to cpp) __STDC__
is not defined at all which satisfies the requirements of the SCO
header files.

> The solution is to use the -traditional-cpp flag to gcc, even when
> building gcc itself.

This is one solution.  Others have been mentioned also.  Below is a
patch for YAS (yet another solution).  It causes __STDC__ to be
defined as 0 unless -ansi is given to gcc, in which case __STDC__ is
defined as 1.  This is also how the SCO cc compiler behaves.  I think
I prefer this method because it doesn't require me to do anything
special (e.g. add -D__STDC__=0 or -traditional-cpp to gcc) when
compiling.  The patch could also be changed to cause __STDC__ to be
undefined without -ansi.  I don't know which is most "correct".
Fixing the SCO header files is probably the most "correct" solution
but I'm not up to that task.

Roger

--- cut here ---
*** config.old/i386sco4.h	Wed Jun 10 23:52:05 1992
--- config/i386sco4.h	Mon Nov 16 23:25:15 1992
***************
*** 72,80 ****
    %{scoxpg3:-D_XOPEN_SOURCE -D_STRICT_NAMES} \
    %{!scoxpg3:%{posix:-D_POSIX_SOURCE -D_STRICT_NAMES}} \
    %{!scoxpg3:%{!posix:\
!   %{ansi:-D_STRICT_NAMES}%{!ansi:\
    -Di386 -DM_I386 -DM_I86 -DM_I86SM -DM_SDATA -DM_STEXT \
!   -Dunix -DM_UNIX -DM_XENIX \
    -DM_SYS5 -DM_SYSV -D_M_SYSV -DM_SYS3 -DM_SYSIII \
    -DM_COFF -DM_BITFIELDS -DM_WORDSWAP \
    %{scointl:-D_M_INTERNAT -DM_INTERNAT}}}}"
--- 72,80 ----
    %{scoxpg3:-D_XOPEN_SOURCE -D_STRICT_NAMES} \
    %{!scoxpg3:%{posix:-D_POSIX_SOURCE -D_STRICT_NAMES}} \
    %{!scoxpg3:%{!posix:\
!   %{ansi:-D_STRICT_NAMES -D__STDC__=1}%{!ansi:\
    -Di386 -DM_I386 -DM_I86 -DM_I86SM -DM_SDATA -DM_STEXT \
!   -Dunix -DM_UNIX -DM_XENIX -D__STDC__=0 \
    -DM_SYS5 -DM_SYSV -D_M_SYSV -DM_SYS3 -DM_SYSIII \
    -DM_COFF -DM_BITFIELDS -DM_WORDSWAP \
    %{scointl:-D_M_INTERNAT -DM_INTERNAT}}}}"
*** config.old/x-i386s4	Tue Nov 17 11:24:39 1992
--- config/x-i386s4	Mon Nov 16 22:57:35 1992
***************
*** 7,10 ****
  CLIB = -lPW
  
  # Seems to be needed with SCO DEV3.2v4.
! X_CFLAGS = -D__STDC__=0
--- 7,10 ----
  CLIB = -lPW
  
  # Seems to be needed with SCO DEV3.2v4.
! /*X_CFLAGS = -D__STDC__=0 */
--- cut here ---
-- 
Roger Cornelius        sherpa!rac@uunet.uu.net       ...!uunet!sherpa!rac
From: gb@buran.fb10.tu-berlin.de (Guenter Becker)
Newsgroups: biz.sco.opendesktop
Subject: Re: Re: Use gcc with X in SCO
Date: 20 Nov 1992 10:33:27 GMT
Organization: ZRZ/TU-Berlin
NNTP-Posting-Host: mir.fb10.tu-berlin.de

In article <1992Nov19.015843.4166@sco.com> garyh@sco.COM (< Gary H >)  
writes:
> 
> You'll need to get the X include files from MIT.  If the program is  
Motif
> based, you'll need the include files from OSF.  All the include files
> (X, Xt, Xm, extensions, Mrm, and uil) are included in the ODT  
Development
> System.
> 
> You can't simply compile X programs with gcc alone.  You'll also need  
the
> X libraries (as well as the header files).  These libraries are also

It's not that bad, at least with gcc2.3.1 under sco-3.2.2 .

Add -DSYSV -DM_XENIX to the gcc compiler options and most trouble will  
disappear. What remains, are a few typedefs in X11/oscompat.h, which are  
also in sys/types.h. 'cc' accepts these without complaining (as tentative  
declarations), whereas 'gcc' rejects them (as double definitions). (K&R is  
not quite clear on this point, which is a known compatibility issue).  
After I removed them from oscompat.h, everything was fine, and I was able  
to translate a large Motif application, and it worked.

Optimizing in gcc is better than in cc :-), and takes about twice as long  
compilation time :-(; however, the time spent in x and xm routines is  
unfornately not affected, as these exist as compiled libraries already. So  
don' expect drastic speed improvements in your user interface.

G. Becker
Xref: sparky biz.sco.opendesktop:750 comp.unix.sysv386:16549 comp.unix.programmer:5314
From: liuwu@acuson.com (Wu Liu)
Newsgroups: biz.sco.opendesktop,comp.unix.sysv386,comp.unix.programmer
Subject: Re: Problems with SCO DEVSYS 3.2.4d include files - help?
Date: 16 Nov 92 18:29:37 GMT
Distribution: na
Organization: Acuson; Mountain View, California

dan@dribble.c-mols.siu.edu (Dan Ellison) writes:
>I am evaluating the SCO devsys version 3.2.4d here and am experiencing
>some real problems with the include files not defining some pretty
>standard things (like sys/types.h and sys/signal.h.)
>
>Specifically, I am trying to build gcc-2.3.1.  I have built it without
>any problems using the 3.2.0 devsys package.  However, when I try it
>under 3.2.4d, I get through the first pass fine, but wehn I start
>trying to compile with the xgcc program I start running into numerous
>errors having to do with the include files.  IT seems that if you
>define _POSIX_SOURCE you get around some of the problwms but create 
>others.  The same is true for _XOPEN_SOURCE.  Fix one, create more.
>
>Has anyone succeeded in building gcc2.3.1 with this version of the devsys
>package?  I'm starting to feel like I am the victim of some cruel SCO
>joke or something.
>
>I should note that most applications I have attempted to install using
>the standrad cc compiler have compiled clean.  Must be some fundamental
>definition or library that is or is not being used.  Any help greatly
>appreciated and thanks.

Well, if this is what I think it is, the problem is due to the fact
that SCO's default C compiler (from Microsoft) defines __STDC__ to
be 0, whereas GCC defines it to be 1.  Take a look in some of the
system header files (stdio.h will do); there are a bunch of:

    #if _POSIX_SOURCE || _XOPEN_SOURCE || !__STDC__

constructs scattered throughout.  This means that having __STDC__
defined as non-zero will fail and leave out everything within that
block.  The solution, at least until Microsoft (or SCO) deals with
their compiler, would be to have GCC define __STDC__ to be zero.
Don't define _POSIX_SOURCE or _XOPEN_SOURCE unless you really mean
to.
-- 
Wu Liu                          Software Engineer, User Interface Group
liuwu@acuson.COM                Acuson
Xref: sparky biz.sco.opendesktop:747 comp.unix.sysv386:16508 comp.unix.programmer:5298
From: drg@candidus.ma30.bull.com (Daniel R. Guilderson)
Newsgroups: biz.sco.opendesktop,comp.unix.sysv386,comp.unix.programmer
Subject: Re: Problems with SCO DEVSYS 3.2.4d include files - help?
Date: 16 Nov 92 14:52:42 GMT
Distribution: na
Organization: Bull World Wide Information Systems, Billerica MA USA

In article <Bxt2yx.9D7@wimsey.bc.ca> sl@wimsey.bc.ca (Stuart Lynne) writes:

   >> Specifically, I am trying to build gcc-2.3.1.  I have built it without
   >> any problems using the 3.2.0 devsys package.  However, when I try it
   >> under 3.2.4d, I get through the first pass fine, but wehn I start
   >> trying to compile with the xgcc program I start running into numerous
   >> errors having to do with the include files.

   >The solution is to use the -traditional-cpp flag to gcc, even when
   >building gcc itself.

   If you add: -D__STDC__=0 to CFLAGS you will have much better luck. 

I had great success by editing ~/gcc-2.3.1/config/x-i386s4 and
changing the definition of X_CFLAGS from -D__STDC__=0 to
-DSTDC_VALUE=0.  The only place that STDC_VALUE is used is in the
compilation of gnu's cpp.  Once cpp is taught to use 0 as the value of
__STDC__ your worries are over.  One note about x-i386s4:  that file
is only used if you configure gcc-2.3.1 for sco3.2v4 **AND** edit
config.sub to fix the case statement which ignores sco3.2v4.  i.e. you
have to make sure that ./config.sub i386-sco3.2v4 returns
i386-unknown-sco3.2v4 and not i386-unknown-sco3.2v2.  If you are
compiling a 3.2v2 system you will probably want to edit x-i386sco to
change the definition of X_CFLAGS.
Newsgroups: biz.sco.opendesktop
From: scott@pascal.geom.umn.edu (Scott S. Bertilson)
Subject: Re: BOOTP implementation on SCO UNIX
Organization: Geometry Center, University of Minnesota
Date: Thu, 19 Nov 1992 22:40:09 GMT

  The nastiest bit when I fiddled with this awhile back was due to
the fact that you can't use "SIOCSARP" directly.  You have to open
"/dev/inet/arp" (whatever it is called) and package the SIOCSARP
inside a streams ioctl call.  I have a copy of a hacked version
of bootpd which I will put up for anonymous FTP as:
	geom.umn.edu:scott/bootpd.tar.Z
--
Newsgroups: biz.sco.opendesktop