thad@cup.portal.com (Thad P Floryan) (07/31/90)
A recent posting by petechen@porthos.rutgers.edu (Peter Chen) ends with:
Oh, I almost forgot about "bash." In case, you haven't heard of it,
it's a superset of Bourn shell. I want to compile it for A/UX since
it has the file completion feature which none of the shell included
under A/UX does.
The A/UX 1.0 ksh, in emacs mode, performs file completion just fine (using
two ESCapes). Has something gotten "broken" in later A/UX releases, or is
it just poor documentation?
Frankly, I'm quite disappointed with the docs accompanying A/UX, both the
online "man" pages and the printed manual set.
For example, I needed to add more HD capacity to one of my company's Mac II
A/UX systems which sported the internal 80MB and an external 20SC drive.
"Simple," says I, "let's just replace the 20MB drive with a Quantum 80S (or
similar) and the problem will be solved." So I shoe-horned a Miniscribe 130MB
SCSI drive into the 20SC's case and proceeded to format; you don't want to
know what I did with the Seagate 20MB drive! :-)
The docs for diskformat give a nice example ("diskformat /dev/rdsk/c8d0s0 ..."
for floppy) which I adapted for the HD per "diskformat /dev/rdsk/c4d0s0 ..."
with no luck. Only in some OTHER obscure document did I find an oblique
reference to "slice 31" referencing the entire disk; finally got it formatted
("diskformat /dev/rdsk/c4d0s31 ...") and a brief sesssion with "dp" allowed
the drive to be mounted and all's working fine now.
Wonderful; my first 4 hours with A/UX is spent doing something that should
have taken only 15-20 minutes. :-(
Now, this was with A/UX 1.0. Yeah, don't laugh. The 2.0 upgrades have been
ordered and are expected momentarily. I have just "inherited" the task of
porting my company's product to UNIX after the other team got nowhere's after
18 months. So, after adding another 4MB RAM to the systems and more HDs, I
should be all set, right? Or so I thought ...
First, some background. I run the Silicon Valley AT&T UNIX Users' Group which
meets at the AT&T West Coast Training Center (see the blurbs in the San Jose
Mercury News, MICROTIMES, COMPUTER CURRENTS, and COMPUTER SHOPPER), so I'm
not exactly a neophyte when it comes to UNIX. I operate my own systems
comprising several 3B1, Motorola 6350, etc. over Ethernet, StarLAN, and "other"
nets, and I regularly use HP-UX, UTS (Amdahl's SysV variant), several AT&T
SysV versions, and other variations. I've literally ported thousands of
programs between these platforms with NO trouble. Note the platforms:
680x0: 3B1, HP-UX, Motorola 6350, AT&T, etc
80x86: AT&T, UNISYS
7300: UTS (Amdahl)
risc: HP-UX
From a compressed EMACS tar file on, say, the 3B1, it takes but 55 minutes to
uncompress the 4.5MB (to 12.3MB), unpack the tar, start a make, and end up
with a new EMACS. Note the 3B1 is but a 10MHz 68010, VM demand-paged system
using ST506 disks (albeit large ones (Maxtor XT2190)). Took only 35 minutes
on an HP9000-855.
From a compressed GNU cc tar file also on the 3B1, it takes but 3 hours to
uncompress, unpack, run thru all the makes to the third level and end up with
a new version of gcc.
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).
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?
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?
OK, I'm not a masochist and I want to get this project going quickly, so I just
ftp'd all the GNU stuff (gas 1.36 and gcc 1.37) from apple.com and we installed
them today (Monday) on our Mac II A/UX systems, and preliminary tests indicate
they (gcc and gas) function.
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.
Some of my concerns include:
1. can "ld" be expected to link a 700Kbyte executable comprising 400 object
files compiled using gcc and gas without dumping core?
That size (700KByte) is based on the executable's size of the same product
on a VAX. Speaking of which, Apple itself is already using my product on
their inhouse VAXes for some interesting applications as reported in mags
such as COMPUTERWORLD.
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?
3. has A/UX passed any version of SVVS (System V Validation Suite)? If so,
which? (And WHICH version(s) of A/UX :-)
4. what kind of support and bug-fix turnaround can be expected from Apple?
Yes, my company and I are official developers in APDA, but recent phone
conversations with APDA have resulted in run-arounds and refusal to even
divulge phone numbers of technical contact personnel; the response was to
write, yes, write (not call) the "Software Evangelists" to plead our case.
Sheesh.
5. is Apple committed to UNIX (aka A/UX), or is(was) A/UX only a marketing
ploy for satisfying government procurement of Macs?
I'm making NO apologies if any of the above offends anyone; these ARE issues
of concern to me personally and, as people who've read my postings on USENET
over the years already know, I speak with candor.
I sincerely want to bring up the product under A/UX as soon as possible using
the Mac II A/UX systems already inhouse, but if the collective net wisdom
suggests this may be folly, I have no compunction calling HP or UNISYS or
others and getting their development systems instead.
Your advice is sought. I'd prefer public discussion, but email is fine, too.
Thad
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]rmtodd@uokmax.uucp (Richard Michael Todd) (08/01/90)
thad@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@chinet.chi.il.us or rmtodd@uokmax.ecn.uoknor.edu
coolidge@casca.cs.uiuc.edu (John Coolidge) (08/01/90)
thad@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@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.
thad@cup.portal.com (Thad P Floryan) (08/01/90)
rmtodd@uokmax.uucp (Richard Michael Todd) in <1990Jul31.182543.5822@uokmax.uucp
>
wrote the first "public" response to my posting; I have also received several
e-mails which are, I'm pleased to say, encouraging.
In appreciation for the comments and to encourage further discussion of
porting issues, I'll answer Richard's points as succinctly as possible:
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.
The formatting wasn't a problem ... the A/UX documentation is. It never
even occurred to me that formatting under A/UX wasn't the "normal" way to do
things.
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.
Many UNIX systems with which I'm familiar have used "0" as the designator for
a disk as an entirety. The docs for "diskcopy" neither detail nor specify the
steps required for formatting a HD, and it was only by chance I stumbled upon
an obscure pamphlet in which I noticed an "en passant" remark to slice "31"
representing a disk in toto.
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).
True. It's been so long I have forgotten the humongous "#define"s in the gcc
source! And there NEVER was a problem compiling GNU EMACS on the 3B1 using
the stock cpp and cc.
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.
The 3.51a kernel was released, free, from AT&T during January 1988. The 3.51m
kernel was released January 1990, free, from AT&T, followed a month later by
the release (by AT&T (again free)) of the 3.51m kernel objects with which
anyone could customize the kernel using Mark Dapoz' "conf.c" and AT&T's
makefile.
Nothing was "broken" with any of those AT&T releases; I'm still using some
software which I last compiled back in 1987; and even commercial products such
as Microsoft Word, Ashton-Tate's dBASE-III, etc. continue to operate fine
across all the kernel and library upgrades for the 3B1 from 1985 to the
present. And that includes the shared libraries.
What was even more amazing, at first, was that the GNU EMACS executable built
on the 3B1 runs, unchanged, on a Motorola 6350, and that the csh from the Moto
box runs on the 3B1. Both the 3B1 and the Moto 6350 were built by Convergent,
so they're hardware compatible. I still prefer ksh; haven't brought up "bash"
yet. I'm still contemplating bringing up the GNU "make" on A/UX so as to get
my hands wet (so to speak) before diving into porting the big project.
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.
Right! I ftp'd the files from apple.com this past weekend and all seems to be
functioning fine.
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.
This comment, and others I've received in e-mail, are exactly what I'm pleased
to hear! None of the prior-seen discussions in this newsgroup have touched
on matters like this and I was gravely concerned that I might have dug myself
into a pit committing to taking over an otherwise-doomed project. Several
test-compiles of various source files were done today and it appears like
we're not going to be hitting any unsurmountable obstacles. Whew. :-)
Actually, I really wasn't too worried, just concerned. After having ported
much of the 4.3BSD "Tahoe" networking software suite to the 3B1 in just one
weekend a month ago, there's not much that can faze me now! :-)
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? :-)
Yes! And I've received independent corroboration of that X11R4 port earlier
today from the porter (portee?) along with a few caveats which I'll summarize
for this newsgroup shortly.
Thank you for your comments and observations.
Thad
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]rmtodd@servalan.uucp (Richard Todd) (08/02/90)
thad@cup.portal.com (Thad P Floryan) writes: >The formatting wasn't a problem ... the A/UX documentation is. It never >even occurred to me that formatting under A/UX wasn't the "normal" way to do >things. Aha. I think I recall you saying that you had A/UX 1.1? Well, I just looked at my copies of the release notes. The release notes for 1.0 included a nice 8-page or so section on how to hook up, format, and partition for A/UX an external hard drive, including telling you how to format the drive using Apple HDSC Setup, how to use dp to repartion, and explaining how s31 is the whole disk. However, for no well-explained reason, this entire section is absent from the 1.1 Release Notes. In short, Apple screwed up on the docs. Fortunately, A/UX 2.0 comes with a book, "Setting Up Accounts and Peripherals on Your A/UX System", which includes a chapter on doing the formatting/ partitioning, including showing you how to do the partitioning with HDSC Setup. > 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 >The 3.51a kernel was released, free, from AT&T during January 1988. The 3.51m >kernel was released January 1990, free, from AT&T, followed a month later by >the release (by AT&T (again free)) of the 3.51m kernel objects with which Yeah, but how much actually changed in those releases? Just at a guess from the version numbers, one would expect that going from 3.51a to 3.51m is a lot smaller change than going from A/UX 1.1 to A/UX 2.0. >Nothing was "broken" with any of those AT&T releases; I'm still using some >software which I last compiled back in 1987; Most of the software I'm using on this system hasn't been recompiled since 1.1; some of it (like the working copy of GNU Emacs 18.44 I have) haven't been touched since A/UX 1.0. All the X11R4 binaries on my system are left over from A/UX 1.1. >present. And that includes the shared libraries. It's unfortunate that I mentioned shared libraries, as my further investigations showed that shared libraries apparently had nothing to do with my Emacs woes. The problem seems to be in handling SIGTSTP, and is something that the Emacs 18.54 port I got from wuarchive is doing, as my copy of the Emacs 18.44 port (the one that's so old it called A/UX by its pre-release name, Oreo), compiles and runs *just fine* under A/UX 2.0. >yet. I'm still contemplating bringing up the GNU "make" on A/UX so as to get >my hands wet (so to speak) before diving into porting the big project. Helpful hint. There's one place in GNU Make where they call one function (setvbuf(), I believe). For no well explained reason, SVR3 and pre-SVR3 systems apparently disagree on the arguments passed to setvbuf, and contrary to what you would expect, A/UX has the SVR3 version. So lie to it and tell it A/UX is SVR3 in the config. options. There are maybe 2-3 other minor little things that have to be twiddled; these are left to the porter as an exercise :-). >Actually, I really wasn't too worried, just concerned. After having ported >much of the 4.3BSD "Tahoe" networking software suite to the 3B1 in just one >weekend a month ago, there's not much that can faze me now! :-) Yow. And you were worried about a little port to A/UX? :-).