While trying to debug a small program with DDD, a popup dialog appeared: DDD: No Source /var/tmp/portage/glibc-2.3.2-r1/work/glibc-2.3.2/buildhere/csu/crti.S: No such file or directory I suppose since there should be no trace, nowhere, of this path, it's a problem of the glibc ebuild. I have compiled my small programm with: "cc -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wall ..." I guess there should be no necessity to search for glibc sources in this case. Proof: kjwolf@golulu $ grep /var/tmp/portage/glibc-2.3.2-r1/work/glibc-2.3.2/ `grep ^obj /var/db/pkg/sys-libs/glibc-2.3.2-r1/CONTENTS |cut -d\ -f2` Binary file /usr/lib/libpthread.a matches Binary file /usr/lib/crt1.o matches Binary file /usr/lib/crti.o matches Binary file /usr/lib/crtn.o matches Binary file /usr/lib/gcrt1.o matches Binary file /usr/lib/libc.a matches Binary file /usr/lib/libm.a matches Reproducible: Always Steps to Reproduce:
i'm pretty sure this is a WONTFIX ... yeah, the binaries record where their source came from so that if you leave the src on your hd, gdb/whoever can locate it ... after all, what would you replace the path with ? /usr/src/glibc ? /usr/local/src/glibc ?
Yep.
To SpanKY: A neutral path? The remnants of something happening during build process somewhere in a local path is never a good choice...
how would you define a 'neutral path' ? besides, if you wish to debug the library, in order to get the source, you just have to run `ebuild <ebuild> unpack` and *bam* the src is there for your debugging pleasure ... as for remnants of the build process, we didnt 'choose' it, the package does it automagically ...
I've been having this problem recently too. I startup gdb, and it says: This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". Then, I type break main, and it reports a breakpoint at an address (instead of at a file:line). I compiled my code with -g and tried it, and then I tried it with -ggdb, same results. Then, I type "run", and it does break at the address for main, but then when I type "l", it says: (gdb) l 1 /var/tmp/portage/glibc-2.3.2-r1/work/glibc-2.3.2/buildhere/csu/crti.S: No such file or directory. in /var/tmp/portage/glibc-2.3.2-r1/work/glibc-2.3.2/buildhere/csu/crti.S I remerged gdb, but it didn't fix anything. I don't see how this can be a "WONTFIX". There's clearly a problem somewhere, even if it's not really in gdb.
this is not a bug if you want the glibc source laying around on your hard drive to debug with, then by all means, keep it there: FEATURES="keepwork" emerge glibc your 'problem' is that you're trying to break in the middle of a glibc routine ... in theory glibc shouldn't be breaking your application so you shouldn't be breaking in the middle of said routine, but we know glibc aint perfect :)
umm...I'm not breaking in the middle of a glibc routine. I'm breaking main(), as I said before. I should be able to break main() in my own program regardless of what parts of the glibc source are lying around.
Ummm....I feel very foolish now. I actually *wasn't* compiling with '-g'. Problem solved. /me slaps himself for programming this late at night
