This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: vfs tapset compilation error.
On Tue, 25 Jan 2011 07:42:49 -0500, fche@redhat.com (Frank Ch. Eigler) wrote:
>The weird thing here is the double-slash in some places
>(/usr/share//systemtap). Is it coming from some personal environment
>variable, or an artifact of a hand-built copy?
Your note gave me an idea where to look, and I found a way to reproduce
the problem.
Indeed the cause of the problem is an environment variable XDG_DATA_DIRS
when one of it's path elements points to a location with directory
systemtap/tapset (this variable started to be used for tapset path searching
as a result of bug #11455).
Still not clear to me why this can cause an error, but on my machine the
problem is reproducable with the latest systemtap from the repository.
Note that there seems to be an important difference between systemtap 1.3
and the one from repository: for 1.3, error occurs even if XDG_DATA_DIRS
search path contains a default search path:
Searched "/usr/share//systemtap/tapset/x86_64/*.stp", found 3
Searched "/usr/share//systemtap/tapset/*.stp", found 69
Searched "/usr/share/systemtap/tapset/x86_64/*.stp", found 3
Searched "/usr/share/systemtap/tapset/*.stp", found 69
For systemtap from repository this won't cause error - it just says something
like:
Searched "/usr/share//systemtap/tapset/x86_64/*.stp", found 3 processed 3
Searched "/usr/share//systemtap/tapset/*.stp", found 69 processed 69
Searched "/usr/share/systemtap/tapset/x86_64/*.stp", found 3 processed 0
Searched "/usr/share/systemtap/tapset/*.stp", found 69 processed 0
The problem occurs only if XDG_DATA_DIRS points to the same tapsets but in
a directory different from default search path. Then identical tapsets
processed twice - once for each search path.
Can please somebody confirm that the problem reproduces elsewhere so
that I would open a new bug?