Created attachment 271240 [details] [review]
build: simplify dtrace configuration

The ability to pass libtool via $(CC) to dtrace and have it respect this
appears to be a feature that is only present in the systemtap version of
the tool.  In particular, FreeBSD (which seems to be using a copy of the
tool from Solaris) doesn't support this.

The result is that, with $(CC) ignored, and a .lo file specified in -o,
we get an ELF written to the .lo.

Instead of trying to have dtrace run libtool we can have libtool run
dtrace.  dtrace is really just a compiler that produces an object file
here, and it even understands -o, so libtool can make the appropriate
adjustments.

There appears to be some prior art for this approach.  A quick search
shows that at least QEMU is using this approach.  It also appears to
work on Linux with systemtap's dtrace and on FreeBSD.

This may regress cross-compilation because the dtrace command will have
no way of knowing which compiler we intend for it to use to produce the
object file.  I say "may" because I don't know if dtrace ever worked in
the first place under cross-compilation.

Note that even with this patch, dtrace on FreeBSD is all kinds of broken.  It only works if the dtrace kernel modules are loaded (which they are not by default) and on 64bit builds you must pass -64 explicitly (due to a bug in dtrace, which I think is assuming the presence of a Solaris command that is not present on BSD).

We may want to replace our check for Mac OS (where we disable its dtrace for being broken for _different_ reasons) with one that actually tries to do a dtrace compile and disables dtrace if that doesn't work...

Comment on attachment 271240 [details] [review]
build: simplify dtrace configuration

yeah, makes sense

Any reason this wasn't applied? It still applies, and still looks like a good (if incomplete) cleanup.

Attachment 271240 [details] pushed as 7563ab4 - build: simplify dtrace configuration