Date: Sat, 10 Jun 2017 16:07:49 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 219909] Userland dtrace in ports / compiling with poudriere Message-ID: <bug-219909-13@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219909 Bug ID: 219909 Summary: Userland dtrace in ports / compiling with poudriere Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: Ports Framework Assignee: portmgr@FreeBSD.org Reporter: matthew@FreeBSD.org CC: freebsd-ports-bugs@FreeBSD.org About 30-ish ports provide some sort of dtrace SDT probes, with many=20 enabling those conditionally on a DTRACE option. Compiling dtrace-enabled ports via poudriere runs into some hurdles: * dtrace(1) expects the dtrace kernel modules to be loaded * invocations of dtrace frequently examine kernel objects under /boot * generating probes.h out of probes.d and compiling the probes does not=20 fit very well into many build systems * in order for dtrace probes to work at runtime, the process needs to be able to access /dev/dtrace/helper=20 poudriere's use of jails to compile means that the first two of these assumptions aren't necessarily true. The need to examine kernel objects can often be avoided by adding -xnolibs to 'gtrace -G' (generate ELF object file) and 'dtrace -h' (generate C/C++ header file) --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-219909-13>