Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 Description of problem: On RedHat 7.3 I had no problems compiling and testing C++ code. Now that I have 8.0 using the gcc 3.2 compiler code compiles and runs fine but when I try to use gdb or ddd they complain about not being able to find source headers that they are looking for in the build directory. gdb looks in the current working directory and the directory where the source for the object was compiled from. It appears that in the past, when libriaries were built that they used headers in the normal /usr/include path but with 8.0 the headers were in the build path. On a system that doesn't have source for all packages loaded in the build path you get these errors when debuging. It appears that the libirarys need to be compiled with the headers in the correct place or gdb has to be setup with hard coded paths to each sub directory in in /usr/include. Can you explain if I am misunderstanding the problem. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.I built a main.cpp that called a constructor of a class. That was all there is in main. 2.The constructor has 7 or 8 lines of code. 3. start ddd or gdb and set a break point at main. Single step into the constructor of the class. Actual Results: Doing the above results in getting a message that indicates that source files can't be found and gives a path to where it expects a header file to be. This path is in the build directory. Single step continues a machine instruction at a time on each step repeating the message until it returns back to the class you generated. Expected Results: When steping through code and execution goes through a piece of code that is not part of my source, code from a library or other system code, I would expect the debugger to make the step accross that entire piece of code as one step and not give any error messages about not being able to find source. If I step by instruction I expect to then see machine code without source for code that comes from these librarys. That is unless I generated the library and had debugging turned on when I compiled it and then I would expect it to look like any other code. Additional info: (gdb) s std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*) ( __out=@0x40012020, __s=0x80497a0 "Welcome to the tracking program for the troop. ") at /usr/src/build/146482-i386/BUILD/gcc-3.2-20020903/obj-i386-redhat-linux/i386-redhat-linux/libstdc++-v3/include/bits/ostream.tcc:624 624 /usr/src/build/146482-i386/BUILD/gcc-3.2-20020903/obj-i386-redhat-linux/i386-redhat-linux/libstdc++-v3/include/bits/ostream.tcc: No such file or directory. in /usr/src/build/146482-i386/BUILD/gcc-3.2-20020903/obj-i386-redhat-linux/i386-redhat-linux/libstdc++-v3/include/bits/ostream.tcc (gdb)
Does this still happen in a newer configuration? Newer gdb, and libstdc++? If it does, can you include a log of the gdb sessin, how the program was compiled and the source file?
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still running Red Hat Linux, you are strongly advised to upgrade to a current Fedora Core release or Red Hat Enterprise Linux or comparable. Some information on which option may be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/. Red Hat apologizes that these issues have not been resolved yet. We do want to make sure that no important bugs slip through the cracks. If this issue is still present in a current Fedora Core release, please open a new bug with the relevant information. Closing as CANTFIX.