vfs tapset compilation error.

[Daniel Fishman]

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?