Debugging 3.21 code under a 2.95.2 build

[Gary Knight]

Hello;
 In perusing the DDD manual, last edited it seems in 2001, I found 
nothing helpful for users who can't get an executable compiled 
'recently' to run under DDD (or gdb) that was built as long ago as, say 
2001. We have a Unix network (Sun Sparks 2.9 or so) where DDD has been a 
workhorse for 'vanilla' C code and C++ executables that were link-loaded 
under gcc version 2.95.2. However, newer codes compiled under gcc 3.21, 
with a different stdc++ library, do not run in DDD (or gdb). They open 
fine, with no warning, but at the run command, the inferior debugger 
dies because it can't find the new stdc++ library.

 It would be helpful to indicate what to do, short of a recompile of 
gdb, to 'fool' DDD to locate the newer library. It is not smart enough 
to notice an environment string (in bash) specifying the path, although 
that path was recognized by the gcc compiler-loader! One solution would 
be to add a command string intended for dbg in the init file, fingering 
the library or path. Anothrt brutish solution is to copy the 3.21 
library into the same old folder where the 2.95.2 libraries exist (or 
whatever version was used to compile gdb in the first place). Or have I 
missed something that should have been obvious?

 Future versions of DDD ought to notify the user at file-open time that 
an executable will want libraries that seem unknown or unavailable to 
the debugger, and even offer suggestions (or dialogue) to  specify the 
library paths, for saving as options to the init file. A concept index 
entry for "dynamic library" or "library references" would be good.

 Cheers, Gary
--

<><><><><><><><><><><><><>
Gary D. Knight, M.Sc.     ^
(613) 520-2600 Ext. 7515  V
5187 MacKenzie bld.       ^   "If you find you can laugh at it
1125 Col. By Drive        V   later, it would have done more
Ottawa ONT. K1S 5B6       ^   good to laugh at the time !"
<><><><><><><><><><><><><>