gcc 3.1 and gdb 5.2?

[Doug Warmke]

Hey, it worked!

Using the -gstabs option fixes the gdb 5.2 core dump.
And doing something like
    setenv SHELL /bin/sh
gets rid of the LD_LIBRARY_PATH mis-settings for csh users.

Is there any way to configure gdb *not* to load your
.cshrc upon invocation?  That is nasty behavior.
Moreover, if you get into gdb and LD_LIBRARY_PATH
(or any other env variable) is obviously set wrong,
and you do "show env LD_LIBRARY_PATH" inside gdb,
it will show you the environment of your original shell,
*not* gdb's actual environment.  Even nastier.

Thanks Joe.

Regards,
Doug



Joe Buck wrote:
> 
> > We are stuck after a variety of experiments.
> > We tried gdb 5.1.1 and gdb 5.2, and we used
> > the latest gnu ld from binutils-2.12.
> >
> > When using gdb 5.2, setting a breakpoint in
> > gdb results in immediate core dump.
> >
> > When using gdb 5.1.1, setting a breakpoint
> > takes effect, but when we try to run, we
> > get a message about libstdc++.so.4: open failed.
> > This in spite of every possible manipulation
> > of $LD_LIBRARY_PATH.  Some transcript
> > exists below to show what's happening.
> >
> > Looks like we'll have to give up on using gcc 3.1
> > on Solaris until someone makes a breakthrough
> > with gdb.
> >
> > Thanks for your help and advice.
> 
> A couple of things to try:
> - use -gstabs to get stabs-style debugging code.
> 
> As for your other problem: you may be bitten by a gdb misfeature if you
> use csh or tcsh; it will source your .cshrc, wiping out your
> LD_LIBRARY_PATH setting if you set it from .cshrc.  One workaround for
> csh/tcsh users is something like
> 
> env SHELL=/bin/sh gdb [arguments]