dward@runxtsa.runx.oz.au (David Ward) (12/28/89)
I have just recently upgraded my 386 from 2.2.3 Xenix to 2.3.2. The O/S
upgrade went well.
I also upgraded the Development system from 2.1 n86 to 2.2 386 (They didn't
have any 2.3 in stock).
The problem I am having is that programs the used to run before are now
getty "Memory fault - core dumped" after being recompiled.
Has anybody run across this problem before?
Is 2.2 Development System compatible with 2.3.2 O/S?
Anything else I should look at.
P.S. Some small simple programs do compile and work.
Thanks...
I am at UUCP ...uunet!runxtsa.runx.oz.au!dward
Internet ...dward@runxtsa.runx.oz.au
I am ...David Ward > Technical Resource Manager
> Hume Computers Pty. Ltd.
> Sydney, Australia
I do not reflect light or the views of my employer and cannot be held
responible for my reactions.larry@nstar.UUCP (Larry Snyder) (01/02/90)
> I also upgraded the Development system from 2.1 n86 to 2.2 386 (They didn't > have any 2.3 in stock). > > The problem I am having is that programs the used to run before are now > getty "Memory fault - core dumped" after being recompiled. I ran into the same problems back when I was running Xenix, but after upgrading to 2.3.0 developers package, the core files went away. -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA uucp: larry@nstar -or- ...!iuvax!ndmath!nstar!larry "NO! QNX is non-standard, not compatible, and is no more Unix than DOS!"
soup@penrij.LS.COM (John Campbell) (01/04/90)
In article <533@runxtsa.runx.oz.au>, dward@runxtsa.runx.oz.au (David Ward) writes: > I also upgraded the Development system from 2.1 n86 to 2.2 386 (They didn't > have any 2.3 in stock). You're lucky they didn't have it in stock! :-) If you've managed to swing 2.2.3 you have got the version I preferred to work with. 2.2.1 isn't too bad, but 2.2.3 _felt_ better... > The problem I am having is that programs the used to run before are now > getty "Memory fault - core dumped" after being recompiled. > > Has anybody run across this problem before? Are you using curses? All too often the stack is not large enough for the dynamic (stack resident) tables used by curses. I'm not sure this occurs for the '386 product, but I _have_ had lots of problems with this in 286 code. > Is 2.2 Development System compatible with 2.3.2 O/S? Yes, 2.2 _is_ quite compatible with 2.3+. I initially used it when compiling the Thoroughbred BASIC Interpreter. BTW, despite problems with the 2.2 development system, I _strongly_ recommend _against_ acquiring the 2.3 dev system. It's _really_ picky and has more broken features that worked in 2.2... I oughta know... I was trying to compile Bidness BASIC under 2.3 and even when I fixed all of the casts and prototypes (you'll need these too!) It _still_ wouldn't work. I found some serious macros that went belly up. -- John R. Campbell ...!uunet!lgnp1!penrij!soup (soup@penrij.LS.COM) "In /dev/null no one can hear you scream"
mark@promark.UUCP (Mark J. DeFilippis) (01/10/90)
In article <70@penrij.LS.COM>, soup@penrij.LS.COM (John Campbell) writes: > In article <533@runxtsa.runx.oz.au>, dward@runxtsa.runx.oz.au (David Ward) writes: > > The problem I am having is that programs the used to run before are now > > getty "Memory fault - core dumped" after being recompiled. > > > > Has anybody run across this problem before? > > Are you using curses? All too often the stack is not large > enough for the dynamic (stack resident) tables used by curses. > I'm not sure this occurs for the '386 product, but I _have_ > had lots of problems with this in 286 code. > Shouldn't occur. The 80286 compiler version uses a fixed stack size (I believe it defaults to 2000 hex bytes). It could be expanded with the fixhdr -f command, or there is a cc option. 386 compiled executables have variable size stacks and do not suffer from the limitations that the 286 does. BTW, on this box I am running SCO XENIX 386 2.3.2, with DS 2.2, and have not experienced these core dumps. I run all kinds of stuff from Netnews, smail, to filepro and Informix, etc... And if anything is going to core dump it is going to be an Informix Esql/C program :-) -- Adelphi University, Garden City, NY 11530 (516) 663-1170 SA @ Department of Mathematics and Computer Science UUCP: philabs!sbcs!bnlux0!adelphi!markd
soup@penrij.LS.COM (John Campbell) (01/13/90)
In article <2259@promark.UUCP>, mark@promark.UUCP (Mark J. DeFilippis) writes: >In article <70@penrij.LS.COM>, soup@penrij.LS.COM (John Campbell) writes: >> Are you using curses? All too often the stack is not large >> enough for the dynamic (stack resident) tables used by curses. >> I'm not sure this occurs for the '386 product, but I _have_ >> had lots of problems with this in 286 code. >Shouldn't occur. The 80286 compiler version uses a fixed stack size >(I believe it defaults to 2000 hex bytes). It could be expanded with the >fixhdr -f command, or there is a cc option. 386 compiled executables >have variable size stacks and do not suffer from the limitations that the >286 does. Actually fixhdr -F xxxx or cc -F ... Anyway, on the 286 the stack _is_ fixed in size and often needs the stack extended past 3000 (hexadecimal, which is what the -F option expects). >BTW, on this box I am running SCO XENIX 386 2.3.2, with DS 2.2, and have not >experienced these core dumps. I run all kinds of stuff from Netnews, smail, >to filepro and Informix, etc... And if anything is going to core dump it is >going to be an Informix Esql/C program :-) My experiences are equivalent. Everything was working until I upgraded the DS to 2.3, then all hell broke loose. DS 2.2 is equivalent to Microsoft C 4.x whilst 2.3 is Microsoft C 5.x. I at least knew how to work around the bugs in 2.2. I also found some funny shift stuff that needed attention so I had to patch around that with an assembly language routine. I also discovered that in grafting on 386 code generation into the C compiler, Microsoft's ability to generate usable 286 code got pretty bad. -- Flame On! Using Microsoft and working in the same sentence can get you lynched. Like Intel, Microsoft can't get the first 7 revisions (or steps) of a product to work without bugs. Funny, isn't it, that Motorola's chips always work correctly? -- Flame Off! Please forgive the flames. I spent about 2 years working on the internals of Thoroughbred BASIC and had to make it work on both 286 and 386 boxes. I consider myself lucky that I didn't pull DOS duty... ------- John R. Campbell ...!uunet!lgnp1!penrij!soup (soup@penrij.LS.COM) "In /dev/null no one can hear you scream"