ghc build failed on dtrace

[J.Gilbey@…]

I just tried doing a port selfupdate; port upgrade outdated, and the build failed on ghc. I cleaned the ghc port and tried again, but the same error occurred.

This is almost identical to the bug I trported in ticket #48149, so I wonder whether there is something systemic wrong with my setup?

Attached is the ghc build log.

Thanks for any ideas you may have!

[J.Gilbey@…]

Oops, I forgot to set "Port" to ghc when I created this ticket - sorry. I don't seem to be able to fix this myself.

[mf2k (Frank Schima)]

In the future, please Cc the port maintainers (port info --maintainers ghc), if any.

[neverpanic (Clemens Lang)]

I'm surprised the build actually uses dtrace, especially since it's useless without root privileges on OS X, and we do builds as unprivileged user.

Is your dtrace a standard installation? What's the output of ls -lash /usr/bin/dtrace?

And here's to random guessing: Did you by any chance put a SUID bit on dtrace? MacPorts' builds are sandboxed, and SUID binaries cannot be run in sandboxed environments. They fail with this exact error message. Console.app would also contain a message about this. You can temporarily disable the use of sandboxing by putting enable_sandbox no into macports.conf, but please don't keep it as the default.

[J.Gilbey@…]

Hi! Here's the dtrace exploration:

Julian-Mac:~ $ ls -lash /usr/bin/dtrace
ls: /usr/bin/dtrace: No such file or directory
Julian-Mac:~ $ which dtrace
/usr/sbin/dtrace
Julian-Mac:~ $ ls -lash /usr/sbin/dtrace
40 -rwxr-xr-x  1 root  wheel    49K 18 Oct 00:46 /usr/sbin/dtrace

So no, there's no SUID dtrace. Hmmm. As you say, I have no idea why the build even tries to use dtrace; somewhere in the configuration step, it must have decided that dtrace was a sensible thing to do.

I checked in configure.ac; it tests for the presence of dtrace. dtrace is then used, if it exists, in rts/ghc.mk, as defined by the variable USE_DTRACE. I don't see any obvious way around this (besides editing the makefile), but I also don't understand why it doesn't test for sufficient privileges to actually be able to run dtrace.

Julian

[neverpanic (Clemens Lang)]

Turns out dtrace isn't actually used to trace anything, but to generate a header file from rts/RtsProbes.d to allow better tracing of Haskell programs. However, my call of dtrace does actually not fail:

"/usr/sbin/dtrace" -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -C -x cpppath=/usr/bin/clang -h -o rts/dist/build/RtsProbes.h -s rts/RtsProbes.d

Did you try running this command manually? What happens if you run the command itself under dtruss(1)? Does Console.app contain any useful information on the problem?

[J.Gilbey@…]

I just attempted a fresh build to answer this question, and it worked perfectly. I have upgraded to OSX El Capitan since the original bug report, so maybe that fixed whatever was the cause of the original problem?

Anyway, unless anyone else has this problem, both this ticket and ​https://trac.macports.org/ticket/48149 can be closed.

Thanks!

Julian

[neverpanic (Clemens Lang)]

Glad you got it working!