Xref: utzoo comp.emacs:4832 comp.unix.microport:2242
Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rutgers!ukma!uflorida!haven!umbc3!cbw1!brian
From: brian@cbw1.UUCP (Brian Cuthie)
Newsgroups: comp.emacs,comp.unix.microport
Subject: Re: GNU Emacs
Message-ID: <121@cbw1.UUCP>
Date: 11 Dec 88 19:03:37 GMT
References: <828@ubu.warwick.UUCP> <28173@tut.cis.ohio-state.edu> <10960@bigtex.cactus.org> <8791@wright.mips.COM> <1138@csuchico.EDU> <429@lehi3b15.UUCP>
Reply-To: brian@cbw1.UMD.EDU (Brian Cuthie)
Organization: CBW, Columbia, MD 21046
Lines: 41

In article <429@lehi3b15.UUCP> mludwig@lehi3b15.UUCP (Mitchell Ludwig ) writes:
>
>Ok, here we go...
>
>I am attempting to make 18.52 (gnu) work on my Microport 386.  The machine
>is running Microport UN*X ver 3.  Internally I've got 2 meg of usable memory.
>When I compile the darn thing, everything goes just grand until the makefile
>tries to execute ld temacs (and a whole lot of .o files...).  Partway
>through the execution of this command I get an error concerning the system's
>inability to add the symbol Lisp_Subr to the symbol table and then I get
>gonged.  I'm using the m-intel386.h and the s-usg-5-3.h in my config.h.  
>My question is, HELP!  How come?  I have a friend using the freakin thing in
[stuff deleted]


Check the amount of disk space you have in the root partition.  I ran into
this problem on a client's system while trying to build a new kernel.  After
scratching my head for a few minutes I realized that all the disk space in
the root partition (/) was gone.  I then found out that when I had asked
them to restore from the backup tape a few weeks ago, they had somehow not
mounted the /usr file system.

I don't know why, but the ld(er) is not very good about error messages when
it runs out of disk space.  This is *so* like many unix utilities.  I like
unix and have been using it for a *long* time, but I can't help but wonder
what universe some of the people who write these utilities live in.   I mean
would it be so difficult to say "ld: out of /tmp space ?"

I can't help but think that the major obstacle to UNIX becoming accepted in
the business community has been the piss poor way in which programs die.
Most of the time the program knows why it can't proceed but it just gives
one of those famous "name: cryptic dribble" messages.  Some utilities are
definitely better than others but AT&T needs to impliment some internal
standard for the way a program dies.  All programs should be required to
give you meaningfull error messages.  Then perhaps, non UNIX people will
begin to overcome their fears of using it.

-brian
-- 
Brian D. Cuthie                                 uunet!umbc3!cbw1!brian
Columbia, MD                                    brian@umbc3.umd.edu