I've run into this same issue recently and I'm working with someone in the Sun Studio group to help me figure it out, but so far, no luck.
I thought that the only thing I needed to do was to make sure that the compiler and the linker were being executed with the -g option, but I've done that and I still can't get dbx to recognize the dynamic libraries has having debugger info. So if I get the answer, I'll post it here. In the meantime, if anyone else knows the trick, I'd appreciate learning it. Lori On 06/11/09 14:12, Steve Gonczi wrote: > I am not succeeding in doing this. > > Opensolaris.sh has option ( D and F) also > bldenv also has an option ( -d) I tried setting either, neither, both.. > Coincidentally, if bldenv is run with -d it outputs a burb mentioning that a > debug build is configured. > If this option is not given on the command line, the blurb says it is a > release > build, regardless of the debug flag settings in opensolaris.sh > > Built full nightly, incremental nightly, and a subset build ( make clean; > make) > from .../usr/src/lib. No cigar, the resulting *.so has no debug information. > (Not stripped, but no debug info). > > I figured I ask before I start looking for the needle in the haystack, maybe > I am missing something obvious. > > Another thing, ztest will load its libraries from the default library > location ( typically /usr/lib), which is > probably not what a developer would want, esp. if a random zfs version > happens > to be already installed on the dev system. > > Fortunately, this one has an easy solution: > set the env variable LD_LIBRARY_PATH to the preferred load location ( > typically > somewhere in the dev workspace). A key point, the location must end in a > semicolon. > > The semicolon causes the location specified to be searched _before_ the > default. > > Perhaps, the build environment should set this, or use "YP," to force library > searches to start inside the build output area where the so-s go. > > Also, as per docs, the opensolaris.sh "t" option is supposed to "build and > use" the .../usr/src/tools. > Well, it just uses the location, but does not build them if they are not > already > there. No big deal, they can be built from the aforementioned dir. >
