Re: Bug#726248: sdt.h conflict with kfreebsd-kernel-headers and systemtap-sdt-dev
On Sat, Oct 19, 2013 at 05:00:48PM +0200, Robert Millan wrote:
> If you want to avoid modifying programs that #include <sys/sdt.h>, why
> not just install it in /usr/include/systemtap/sys/sdt.h ? Then you can
> build them with -I/usr/include/systemtap so that your version takes
> preference.
But then programs that expect the header to be in the default place
wouldn't build. The whole idea is that programs that use sys/sdt.h
(and optionally the dtrace script) to use DTRACE_PROBE macros to
define SDT probe points get them without having to change anything
to their build system. They just detect in configure the sys/sdt.h
is available (possibly checking for the dtrace script and whether
the compiler is capable of building with DTRACE_PROBE macros).
That is how for example qemu, java hotspot or libreoffice do it.
The default sys/sdt.h header should match the toolchain and user space
you are using. It looks to me that for Debian that should be the one
from sdt-dev, not the fbsd specific kernel header. That way all
the default tools can get and use the SDT probes.
But if you think that on kfreebsd programs should be build against
a different sys/sdt.h that is fine too (but then programs like gdb
will not work with the SDT probes in programs and libraries or will
be less efficient when handling things in glibc and libgcc). All that
is really needed is that the sdt-dev package can be made arch:all.
Whether or not it is installed by default and/or whether it provides
the default sys/sdt.h alternative header is secondary. I don't know
enough about Debian packaging to suggest the right course of action
of making the package arch:all. But that is what Bug#726248 is really
about as I understood it. systemtap-sdt-dev: should be "Arch: all"
so gcc and libc can B-D on it.
How did you resolve the conflicts between kfreebsd-kernel-headers
and glibc-headers? Maybe the same solution can be used here?
Does any user space program Debian actually use the kfreebsd
sys/sdt.h variant? Are there any programs that can use the SDT
probes it generates? If not, then maybe you can just not install
it for now and get the conflict between the packages resolved?
Cheers,
Mark
Reply to: