When users provide a CFLAGS envar which containts newlines, the dtrace script fails with:
: No such file or directory
For example, the fedora rpm spec file for creating packages defines:
CFLAGS="-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -g \
and the multiple lines cause the dtrace script to die. Possibly, this error has caused packagers to believe systemtap USDT's have not been available in project where in fact it has been, because using "--with-dtrace" caused compilation errors which were taken as due to general unavailability of the real dtrace tool on linux.
The problem is towards the end of the `dtrace script`:
cmd=split(cc1) + defines + includes + split(cflags) +\
["-fPIC", "-I.", "-I/usr/include", "-c", fname, "-o",
filename + suffix]
where cflags should be sanitized so that examples like the above CFLAGS are tolerated.
I'm having trouble reproducing this with a plain set of commands lines. Do you have a copy&paste'able recipe to trigger the behaviour?
(In reply to Frank Ch. Eigler from comment #1)
> I'm having trouble reproducing this with a plain set of commands lines. Do
> you have a copy&paste'able recipe to trigger the behaviour?
Sorry, this should do it.
export CFLAGS='-g \
dtrace -G -s node_provider.d -o node_provider.h
commit 100bca3f124 should fix this. The problem here seems to be the \ character in the string rather than new lines, but the patch nukes them both.
(In reply to Frank Ch. Eigler from comment #3)
> commit 100bca3f124 should fix this. The problem here seems to be the \
> character in the string rather than new lines, but the patch nukes them both.
ah yes, a case of tunnel vision on my part.
Thanks you again for being o responsive, I usually dread plunging into bugzillaz for fear of either limbo or pedantic deflection but it's been simple and quick to get hiccups in stap addressed. I salute you, sir.