klamer@mi.eltn.utwente.nl (Klamer Schutte -- Universiteit Twente) (02/07/91)
david@doe.utoronto.ca (David Megginson) writes: >>BTW, when GCC compiling under gulam, "make" seems to 2-bomb out after some >>arbitrary period of happy mass compilation, ditto Ksh but less frequently. >>Under Ksh, problem seems to go away after the third/fourth round of mass >>compilation (with -g, without -g, with -gg, without -gg, ad nauseam) but return >>after a warm boot. Anyone shed any light on this --- I have a suspicion that >>it's a malloc() problem, but it's outside my field. >> >Aha! I suspect the 40-folder limit. You should be able to find a fix >for it on your local BBS. If you already have foldrxxx.prg (or whatever >it's called) installed, raise the number. Having experienced similar problems as described above using TeX ;-( i came to the conclusion that it was memory management, not the 40-folder limit (foldr200.prg didn't help; shuffling memory did sometimes. also the available memory sometimes came down to a whopping 10k -- not enough for TeX (I am stymied)). My solution to this "feature": use tos 1.4. I am now running without foldrxxx.prg && cache020.prg and have not experienced the problem. Klamer -- Klamer Schutte Faculty of electrical engineering -- University of Twente, The Netherlands klamer@mi.eltn.utwente.nl {backbone}!mcsun!mi.eltn.utwente.nl!klamer
gjh@hplb.hpl.hp.com (Graham Higgins) (02/08/91)
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. ------------------------------------------------------------------
david@doe.utoronto.ca (David Megginson) (02/09/91)
In article <GJH.91Feb8105528@ghiggins.hpl.hp.com> gjh@hplb.hpl.hp.com (Graham Higgins) writes: > >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? > I've had success with gdb, but it's been very mixed. When I try it on large programs, there is not enough stack space for the symbol table (yes, it uses alloca, I guess), and on medium-sized programs, it often loses synch with the source code. Oh well, ... for now, I just bring my source to a Sparcstation, recompile it there, then use gdb to find the error--it's faster than wasting my time on the ST trying to do it. It would be __great__ if someone could port szadb to gcc, so that it could read the gcc symbol tables. Since gcc can leave local as well as global symbols in, it would be pretty useful. David -- //////////////////////////////////////////////////////////////////////// / David Megginson david@doe.utoronto.ca / / Centre for Medieval Studies meggin@vm.epas.utoronto.ca / ////////////////////////////////////////////////////////////////////////