Resolved Re: [ale] 'gdb' and *.so libs

[John Mills]

Chris -

Thanks for the help. I include the solution in case it's helpful to 
another pilgrm.

On Wed, 5 Nov 2003, Christopher Fowler wrote:

> Did you place the shared object in LD_LIBRARY_PATH ?

Yes, and also in the set of '-L' paths and '-l' libs to link.

> Maybe try using the -c option of gcc so you'll have access to the code.

Actually that's the '-g' - "info gcc" basically says, "Use '-g' unless you 
are completely sure you _don't_ want it." (Also, '-c' prevents linking.)

> On Wed, Nov 05, 2003 at 04:15:40AM +0000, John Mills wrote:
> > ALErs -
> > 
> > This may be a building question, or a 'gdb' question.
     The former --^^^^^^^^

> > I am trying to debug a shared library I built, but find I can't step down 
> > from my top-level app into the library routines.

> > Questions:
> >  1) Did I make the lib in a sensible way? It seems to have linked OK.

  Ans: We'll see when it works, but that was probably OK.

> >  2) Should I be able to debug into it from the app which uses it?

  Ans: Apparently _not_. I built a statically linked executable and can
       debug into it, set breaks, etc., without problems.

       Since all my sources and objects are made in the same directory,
       a static link was a "no-brainer", just changing my Makefile 'link'
       line to say:
         	@$(CCEXE) $(INCLUDES) $(LIBS) -g -o $@ Switchbox.o $(OBJS)
                                        locally compiled objects --^^^^^^^
       (and of course dropping the shared lib out of LIBS.)

Thanks for the input. I caused me to look more carefully at my Makefile, 
which is a little healthier as a result.

I already found the first spot where I try to dereference NULL - a
_BadThing_(TM).

 - John Mills
   john.m.mills at alum.mit.edu