Is A/UX viable? Your advice sought

[John Coolidge]

thad at cup.portal.com (Thad P Floryan) writes:
>Wonderful; my first 4 hours with A/UX is spent doing something that should
>have taken only 15-20 minutes.  :-( [disk formatting]

You had it easy! :-) Try doing the same sorts of things with SunOS
4.x... never have so many wasted so many hours so needlessly. At
least A/UX doesn't (in my experience) kernel panic when you change
the disk values to non-default values the documentation says are
supported! (no smiley, I lost too much sleep on this one).
>In other words, what's so different about A/UX that it makes porting gcc and
>EMACS (and many other programs, per the postings I'm reading here) so darned
>difficult?  Isn't A/UX (all versions) at least based on SVR2?

Politics, pure and simple. The FSF refuses to fold A/UX support
into their code due to Apple's look-and-feel suit. Thus, those
of us who care about these things have to do the code maintainence
ourselves (and distribute the patches by word of mouth). gcc and
emacs are big packages, and there's lots in there that's highly
machine and os specific.

>Since I'm also a compiler writer (among other things), I'm quite familiar with
>hardware architecture (nearly 3 decades in this racket :-) and I fail to see
>what should be so different (in, say, gcc) for a 68010 3B1, a 68020/030 Mac II,
>a 68030 HP9000-350, etc?   Is it that the A/UX libraries differ so much from
>other UNIX systems?

Nope, the A/UX libraries are very standard. Admittedly, this means
they suffer from the same IO bugs as other SYSV stdio's (see the
g++ patches for info). If you read the gcc patches, you'll find
the changes are almost entirely "convenience" changes (arguments
to system commands, predefined symbols, etc), changes to produce
assembly that the SGS-format assembler will allow, #defines to
remove incompatible bits, etc. If you then look at what gets
patched for gcc when using gas, the patches are even less. Yes,
there are incompatibilities, but most of these are found when doing
strange BSD-style I/O things and the like.

>Now I'm faced with porting the 12MB of (uncompressed) source comprising my
>company's product and I'm starting to have some doubts about A/UX being a
>reasonable port platform based on other peoples' problems as reported and
>posted here.  I don't want to get 2 months into this project and discover
>there's not a snowball's chance in Hades getting it to work.

I can sympathize with you there! :-)  Without knowing exactly
what you're doing, I can't say "it will work". There's a pretty
good chance that it'll go smoothly, though...

>1. can "ld" be expected to link a 700Kbyte executable comprising 400 object
>   files compiled using gcc and gas without dumping core?

Haven't tried it in that case, yet. However, I've linked 700Kbyte
executables compiled with gcc and gas which were comprised of
50-100 object files (gcc, g++, libg++) and they're running fine
now. Using the old gcc/as system I've built libX from the MIT
tapes, and that uses 300+ object files in an ar archive. No
problems...

>2. what "breaks" so many programs between the several different versions of
>   A/UX?  Will A/UX 2.0's shared libraries (finally) stabilize the diffs?

Very very little actually broke between 1.1 and 2.0. We had both
for a while, and all the 1.1 binaries I tried ran (didn't try
emacs, though --- but all of X, gcc, g++, bash, and lots of
our development tools).

>5. is Apple committed to UNIX (aka A/UX), or is(was) A/UX only a marketing
>   ploy for satisfying government procurement of Macs?

My impression, based on experience as a beta site and communications
with Apple employees (NOT speaking for the company! :-)), plus
reading some of Apple's employment ads for the A/UX group (quite
a few positions), is that Apple is committed to A/UX for the long
haul. They've put a lot of work into 2.0, work that doesn't affect
government procurement requirements for UNIX-compatible systems
(how many government contracts require UNIX with MacOS support? :-)).
I think the "government procurement" argument may have been fair
w.r.t. 1.0 (and maybe 1.1). They're not fair w.r.t. 2.0, IMHO.

We've got a shared environment with lots of platforms (Sun 3&4 w/
SunOS 4.x, Encore Multimaxes with UMAX 4.3, IBM RT's, AT&T 6386WGS's,
DG AViiON's, HP 9000/835's, and even an AIX machine). Of all the
workstations, the A/UX machines have been the easiest to integrate
w.r.t. NFS, YP, and software. I've got a Mac on my desk, not one of
the others. Admittedly, I'm biased in favor of the Mac (I've got
one on my desk at home, too!), but I chose the Mac, not one of the
others, because I like working on them. I also like compiling on
them --- most everything off the net compiles very easily. The
big packages that you see discussion about porting in this group
are usually ill-behaved and/or highly machine dependant. You don't
see traffic about the many packages that compile w/o trouble,
because they're not very interesting to discuss...

--John

--------------------------------------------------------------------------
John L. Coolidge     Internet:coolidge at cs.uiuc.edu   UUCP:uiucdcs!coolidge
Of course I don't speak for the U of I (or anyone else except myself)
Copyright 1990 John L. Coolidge. Copying allowed if (and only if) attributed.
You may redistribute this article if and only if your recipients may as well.