Thanks, Pete I see from further investigation that gcc wants me to be more actively concerned with memory management than was required under Visual C, and I was logging on to apologize for bothering the list. I posted because this code ran cleanly under Visual C, so I thought I ran into a Linux nuance
It looks as though I was running into problems when trying to scan an input file using c notation which is less efficient of memory, so I'm in the process of revising all of the I/O to use c++ resources. Still, it comes as a surprise, but I'm very early on the gcc learning curve This is a large theoretical problem I was attacking so my initial preference was not to alter anything that didn't requiring fixing, but the code is certainly cleaner after reworking In general, I am beginning to notice that gcc's posture is that you do more for yourself. It also seems to be strictly limited to ANSI c. For example, there doesn't seem to be any support for min, max, and itoa and I ended up writing/rewriting that portion of the code BTW, I notices that my non-working install of XFree86 3.3.6 (?) is also generating Segmentation faults, suggestive of bugs in the newest release. I've posted this to their developers Is there a separate users group for gcc? David ----- Original Message ----- From: Peter Ross <[EMAIL PROTECTED]> To: davidturetsky <[EMAIL PROTECTED]> Cc: <debian-user@lists.debian.org> Sent: Saturday, February 12, 2000 11:05 PM Subject: Re: Segmentation fault > On 13-Feb-2000, davidturetsky <[EMAIL PROTECTED]> wrote: > > I am executing a Linear Program program I wrote and compiled. It > > terminates without generating output (but creates the output file) > > with a "Segmentation fault" > > > A segmentation fault occurs when you attempt to access memory that you > are not allowed to (usually deferencing an invalid pointer). > > > I'm trying to convert programs to run under g++ which I previously > > developed using Visual c 5.0 and would appreciate any help in sorting > > this out > > > > Is there a log which is generated which might provide further details? > > > You can compile with the -g switch to turn debugging on, and then use > gdb to debug the program, and it will tell you which line caused the seg > fault. > > Pete
