Is A/UX viable? Your advice sought

[Richard Michael Todd]

thad at cup.portal.com (Thad P Floryan) writes:
  First, as to your disk formatting problems.  You're the first person I
ever heard of who's ever done the disk formatting and partitioning under
A/UX.  Everybody else either used Apple HD Setup or Silverlining to 
format and partition.  However, *every* Unix system I've ever heard of required
you to use the device corresponding to the full, unpartitioned disk (on
A/UX, c?d?s31, on others ???g or somesuch) to do formats and partitioning,
not one of the devices corresponding to a partition.  Hence, the requirement to
use /dev/rdsk/c?d?s31 should come as no surprise.  

>Now, I've only started reading this newsgroup 2 weeks ago, but I'm left with
>the distinct impression that porting software to A/UX is a royal pain, and
>that it's a MAJOR effort to bring up applications which convert just fine on
>what "should be" compatible architectures (e.g. other 680x0 systems).
 
   As I recall from back when people were porting GCC to the 3B1, they were
having problems about as severe as the Mac porters were (mostly from the
same reason, namely that the stock SysV compiler has fixed table sizes that 
overflow on GCC source).  The reason that it's so easy to compile stuff on
the 3B1 is that somebody's *already* done the port, and it's included in the 
official GCC sources.  RMS refuses to include support for A/UX in the official
GCC, etc., sources for political reasons, so the GCC, etc., ports to A/UX
are not supported by the FSF, but are instead supported by the people who 
actually did the port (mostly, David Berry of Apple).  Also, when was the last
time AT&T shipped a new OS for the 3B1?  Not anytime in the last couple of
years, I believe.  If they had, I wouldn't be surprised if you heard of things
breaking on the new release, just as some of them seem to on A/UX 2.0.
(For the record: the only GNU program I know of that's having problems on
A/UX 2.0 is Emacs; more on that below.)

>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?
SVR2 with Berkeley extensions, yes.  The problem in porting GCC was simply that
the stock C compliler had fixed-length table sizes, and those tables would
overflow when confronted with GCC source.  (If you've ever seen GCC source,
you'd understand why...)  The current A/UX 2.0 C compiler has a command-line
option to boost the table sizes, making it possible to compile GCC.  Not that
it's really important, since GCC binaries are already available for ftp,
and once you've got GCC, there's no problem.  

  As for Emacs, Emacs is well known for doing all sorts of nasty and unportable
things (like replacing crt0.o with its own code, and doing an undump).  These
things break on lots of other systems besides A/UX 2.0.  Something fairly 
subtle is going on here, and A/UX 2.0 has only been shipping a few weeks. 
Give us a little while to figure out what's going on...

>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?
  Not really.  In fact, the GCC port pretty much treats the Mac as if it was
a 3B1 (well, not quite, as it supports 68020 instructions).  As far as I know,
both A/UX and the 3B1 Unix cc and as are basically the *same* Motorola/SGS
development system.

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

  Well, I don't think I've ever done 400 object files, but I have done 700K
(and larger) executable. gcc-cc1 is ~500K, and it was linked using A/UX ld.
Check out the -A (I think) option to boost the table size as big as you want.

>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?
  Actually, in the case of GNU Emacs, I suspect it's the new shared library
support in crt*.o that's causing part of the problem.  As I said, Emacs
is doing all sorts of nastiness here.  I haven't heard of any other programs
that have obviously broken under A/UX 2.0.  Certainly I haven't run across any,
though I've only recompiled a few programs so far (smail, deliver, C News). 
I've heard reports on the net that X11R4 still compiles under A/UX 2.0 without
problems.  Is 50+ Meg of source that still compiles enough to convince you? :-)
-- 
Richard Todd   rmtodd at chinet.chi.il.us  or  rmtodd at uokmax.ecn.uoknor.edu