On 19/10/2013 02:57, Mark Wielaard wrote: >> How compatible are the different implementations? > > They are meant to be source compatible so that if programs use > DTRACE_PROBE macros they get build with SDT probes that systemtap, perf, > gdb, etc. can use to introspect the program. High-level overview: > http://tromey.com/blog/?p=687 > Implementation bits that describe the ELF sections created: > https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation > >> If they're meant to be >> bit-by-bit compatible, then it should be possible for systemtap-sdt-dev >> to just skip this file on kfreebsd-* so that applications will use the >> FreeBSD version. Do you think this could work? > > I suspect, but haven't checked, that the sys/sdt.h variant in > kfreebsd-kernel-headers is also source compatible, but might produce > different ELF section bits, so that tools like gdb won't be able to read > the SDT probes when that version is used.
I see. That's what I am worried about :-( > But the real goal is just to have the sdt-dev package be arch:any. They > don't have to be used on the Debian kfreebsd arch if really not needed, > as long as they don't conflict in such a way that that would prevent the > package being arch:any. Which is why I suggested extracting your > sys/sdt.h variant also in a separate package (not being build > essential), so that either can be installed (even if they would conflict > with each other). But note that I am not a Debian packager, so I might > miss some other more obvious solution. I understand but the <sys/*> namespace is for system headers. As useful as they may be, we really shouldn't have other libraries collide with it... (it's bad enough glibc and kfreebsd have different ideas on what "system headers" means already). 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. -- Robert Millan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
