This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: compiler problem


Hello.

On Sun, Jul 24, 2005 at 12:48:25PM -0700, Fred J. wrote:
> ../14/makefile looks like this
> **************************************************
> include ../makefile
> 
> in the parent directory I have this makefile
> **************************************************
> OBJS = main.o
> CFLAGS= -g -Wall
> proj1 : $(OBJS)
> 	$(CXX) $(CFLAGS) -o $@ $(OBJS)		#CC -o proj1 $(OBJS)
> the macro @ evaluates to the current target.
> 
> clean : 
> 	rm -f $(OBJS)
> 
> I did 
> sam@debian:~/Exercies/ThinkingInC++/Vol1/C03/13$ make
> which went ok.

How does 13/makefile look like?  Does 13/proj1 depend on 14/main.cpp?

> how can I know if the executable programs did or did
> not record the directories of the source files from
> which it was compiled. and if it did what are they?

These may help:

$ strings proj1 | grep bitwise.cpp
$ readelf --debug-dump=info proj1

> (gdb) break bitwise.cpp : 11
> No source file named bitwise.cpp.  <-----this problem
> Make breakpoint pending on future shared library load?
> (y or [n]) 

GDB does not look for the source file right now, when you're setting
the breakpoint.  This error seems to indicate that the executable
itself has no information about the source file.  In fact, you can set
breakpoint even on files you have already moved or deleted; GDB just
won't be able to show the line the breakpoint was set at.

-- 
Alex J. Dam


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]