Xref: utzoo comp.sys.atari.st:34806 comp.sys.atari.st.tech:1356
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!sdd.hp.com!hplabs!otter.hpl.hp.com!hpltoad!ghiggins!gjh
From: gjh@hplb.hpl.hp.com (Graham Higgins)
Newsgroups: comp.sys.atari.st,comp.sys.atari.st.tech
Subject: Re: tos bug Was: Using GDB
Message-ID: <GJH.91Feb8105528@ghiggins.hpl.hp.com>
Date: 8 Feb 91 10:55:28 GMT
References: <1991Feb1.170826.791@rodan.acs.syr.edu> <GJH.91Feb4115042@ghiggins.hpl.hp.com> <1991Feb5.124207.11850@doe.utoronto.ca> <klamer.
Sender: news@hplb.hpl.hp.com (Usenet News Administrator)
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Lines: 60
In-Reply-To: klamer@mi.eltn.utwente.nl's message of 7 Feb 91 08:18:09 GMT
Nntp-Posting-Host: ghiggins.hpl.hp.com

I had a look at my system setup following Dave's suggestion. I find that the
ICD HD driver already gives me 250 folders, so it can't be that. I too suspect
memory management (malloc? sbrk?). It's a bit of a pain as, under Ksh, the
commandline args output whilst compiling are single, unbroken lines, so I can't
tell which file it was compiling when it bombed (the filename is about 3" to
the left of my screen :-( )--- but it still leaves behind an
improperly-compiled (improperly written/saved?) .o file, which needs to be
deleted before restarting the compilation. 

The only things in the AUTO folder are COPYFIX, FSELECT, ICDTIME and MINT.
There's a 60k DOS buffer, a 20K disk cache and 250 folders (from the ICD HD
driver). I wonder if I need to turn on the write verification?

BTW, Eric Smith noted that -fomit-frame-pointer si inimical to -g/-gg and that
he expected GCC to have mentioned this fact (RTFM, Graham -- probably).  Dave
Megginson says that he's had success with GDB using the unisb GCC, but that the
internal gdb stuff has been stripped out and it only produces dbx info. I
rmember Edgar Roeder mentioning this --- but what's the net effect? I mean what
effect does that have on the functionality of GDB?

Just to satisfy my curiosity ...

Has anyone else suffered from Error 66 (invalid program load format) errors on
posted stuff? The recent nroff posting (manpager) yields this error, whilst
lessbin was fine. I also remember jbammi once being surprised that a preloaded
TeX binary he distributed showed the same error. What I find odd is that no-one
else has mentioned any problems with the manpager. Is it just my system, I
wonder?

I also had to recompile flib.ttp in showdvi-1.0. Now I've seen a README
endorsing showdvi-1.0 from jbammi and would have thought that he'd have
mentioned any problems. Flib crashed with an "fseek" error and GCC complained
about the usage of a short. I (arbitrarily) replaced the short with an int and
it seems to work OK --- at least it will create libraries and showdvi can use
them OK. I believe that the fseek problem might be down to the fact that the
binaries were compiled with Turbo-C, but I'm curious to know whether anyone
else has had the same problem.

BTW, dviatari crashes out on Jeff Long's deskjet font files (300 -> fonts),
apparently seeing Character 0 more than once. Anyone got this to work
successfully? I tried using single fonts but all dviatari would print was (and
here I quote) "G000680c6" at the top of each page. However another dvi printer
driver (dvidsk5) worked fine on those same fonts. I suspect a problem with
dviatari's compilation --- anyone seen the sources of this?

Thanks for the info. Still trying.

Cheers,

Graham
======

------------------------------------------------------------------
Graham Higgins             	|  Phone: (0272) 799910 x 24060
Hewlett-Packard Labs    	|  gjh%ghiggins@hpl.hp.co.uk
Bristol                       	|  gjh%ghiggins@hplb.hpl.hp.com
U.K.                          	|  
------------------------------------------------------------------
Disclaimer: My opinions above are exactly that, mine and opinions.
------------------------------------------------------------------