On Thu, Jun 18, 2009 at 10:57:45AM -0700, Steve Gonczi wrote:
> I managed to get the ztest debug compile, using the technique written up in
> this thread.
>
> One thing is still not working: Trying to apply the same methodology to an
> userland
> command (e.g. fashioning a debug-able zpool command) does not work.
>
> No matter what I do, my freshly recompiled zpool command insists on loading
> its
> libraries from the system locations ( /lib and /usr/lib) and not my
> workspace
> location (where the debug libraries are).
>
> I have a LD_LIBRARY_PATH set to where the debug lib's are ( actually 2
> locations
> separated by ":" and terminated with a "\;". Using the same settings I use
> for ztest,
> works like a charm there.
What does:
ldd /path/to/zpool
output?
You should generally use:
LD_LIBRARY_PATH_32=/path1:/path2
for 32-bit libraries and binaries, and
LD_LIBRARY_PATH_64=/path1/64:/path2/64
(where 64 could also be "amd64" or "sparcv9", depending upon your ISA)
There should be no ';'s in LD_LIBRARY_PATH.
> If you have managed to debug any of the usermode commands, please share
> your experience.
>
> I continue looking at this, my current theory is maybe the library
> search location is made fixed during the build.
Unless:
elfdump -d /path/to/zpool
contains a "RUNPATH" or "RPATH" line, the search location is not fixed. The
default build environment does not set a runpath.
Is your zpool binary setuid? That will turn off LD_LIBRARY_PATH* searching.
Cheers,
- jonathan
>
> Steve
> --
> This message posted from opensolaris.org
> _______________________________________________
> zfs-code mailing list
> zfs-code at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-code
