Re: Bug#726248: sdt.h conflict with kfreebsd-kernel-headers and systemtap-sdt-dev
Hi,
as 726248@bugs.debian.org only goes to the maintainer I'm resending this
with a wider Cc list.
-Timo
-----Original Message-----
From: Mark Wielaard <mjw@redhat.com>
Sent: Fri, 18 Oct 2013 10:50:15 +0200
To: 726248@bugs.debian.org
Subject: Bug#726248: sdt.h conflict with kfreebsd-kernel-headers and systemtap-sdt-dev
On Fri, 2013-10-18 at 10:39 +0200, Robert Millan wrote:
> I'm sorry, but I just can't see how this could fly. If systemtap-sdt-dev
> is not meant unusable on non-Linux architectures, and you provide it in
> them, you have to be able to deal with the fact that this package will
> fail on them.
It is certainly meant to be usable for software that wants to use SDT
probes (like glibc in this example) and software that wants to
read/inspect the SDT probes embedded in other software (like gdb in this
example).
> I don't think it does any serious harm to kfreebsd-* ports that
> systemtap-sdt-dev is available despite that it is unusable. However if
> this is inconvenient for other reasons, we really can't help you about
> it. This package shouldn't be provided for kfreebsd-* in first place.
Does kfreebsd use gcc/glibc/gdb/etc? Then it should be available for it
so that software that uses STAP/DTRACE_PROBE SDT macros can be build on
it.
The confusion might be that it has systemtap- in the package name (that
is because it originated through the systemtap project). And systemtap
at the moment is indeed linux kernel specific. But the sys/sdt.h header
(and dtrace compatible python script) provided by the package are not
tied to systemtap at all. Other tools like perf and gdb provide other
consumers of the SDT probes.
Reply to: