brian@natinst.com (Brian H. Powell) (03/15/90)
I've had the dubious honor of working with SCO Unix for the past few
weeks in hopes that we can port one of our products to X Windows on 80386
machines. I've done a fair bit of UNIX programming, but it's all been
Berkeley-oriented. (E.g., 4.2BSD and 4.3BSD on Vaxen, and SunOS 4.x on Sun
3's.) I've also done a substantial amount of work porting/installing various
programs I've obtained from the net on SunOS 4.x, so I have run into the
problem of source not matching the operating system exactly (having to include
new files, uninclude others, #define certain things, substitute one system
call for another, etc., etc., etc.)
Now I've got this SCO Unix stuff. I'm not particularly pleased. It
takes my porting experience to new extremes. It's one thing that I'm in
System V.3-land, but I get the impression from the include files that I'm on
the border with Xenix-land also. Somehow, I get the impression that things
are so Xenix-compatible that they are no longer V.3 compatible in minor
(annoying) ways. But I don't know enough about V.3 to answer that for sure.
Maybe somebody with more experience can say.
As examples of things that annoy me, let me offer:
If I want to compile an X program under SunOS, let's say "xbounce", I just use
the libraries "-lX -lm". Under SCO Unix, I have to add
"-lX -lm -lsocket -ltlisoc -lnsl_s"
to the link command. That's fine if that were always the right set of
libraries, but there've been some programs where I couldn't ever figure out
the right order and the right set of libraries to make the program link.
To get the recently posted "vine" program to work, I had to add a #include
before another particular #include so that the second #include would work find
it's correct types. (All these were in /usr/include. Why didn't that second
include #include the file itself?) I also had to edit an include file (in
/usr/include/sys) to add a guard, so that it wouldn't try to redefine
everything if it tried to include that same include file again. (I'm not at
all a big fan of editing /usr/include files to make them work right.)
Finally, I had to add a #undef SIGCHLD because I don't think it should have
been #defined for this system.
I also have to put up with mysterious "features" of this UNIX
implementation. I have to put up with an out-of-date Motif (snapshot 7), and
a prerelease network product. I don't expect we'll get X11R4 for many months.
I have to put up with the X server mysteriously exiting and logging me out. I
have to put up with the X server freezing (until reboot) when I run xman on
our sun (to display under SCO). I have to put up needing to reboot several
times a day to get things to start behaving "normally". I have to put up with
fsck telling me there are several 0-length unreferenced files after most X
crashes. (I don't know if this is "the inode problem", or if the files are
temporary files that really are 0-length, or if it's trashed something. I
think maybe a little of each; I have noticed some files missing from time to
time, but not as many as fsck mentions.) I used to have to put up with the
Microsoft C compiler for "cc". I fixed that.
Having got all this off my chest, I'd be happy to hear from other users
who do or do not have these problems. I'm interested to hear about all 386
Unixes, not just SCO. I want to hear from __users__, not from salesmen. I
want to know how common my experience is; whether it's just SCO UNIX, or if
it's all ISC-based UNIXes, or if it's all System V.3 machines.
I'm concerned that if our include files are so "out of whack" for Xenix
compatibility, that our program will require a lot of senseless adjustments to
make it work under a "real" UNIX. Oh, if only V.4 were usable now.
I don't want you to get the impression that SCO is worthless; it pleases
me sometimes. I especially like the man pages that have a "Value Added"
section to let me know that SCO did this program themselves. Seriously, some
(perhaps most) things work great. (I won't be really happy, though, until I
get emacs to compile and run under SCO.)
Thanks in advance, and thanks again for letting me vent my frustration.
Please mail responses; I'll summarize if appropriate.
Brian H. Powell National Instruments Corp.
brian@natinst.com 6504 Bridge Point Parkway
uunet!cs.utexas.edu!natinst!brian Austin, Texas 78730-5039
AppleLink:NATINST (512) 338-9119