Opened 5 years ago

Closed 5 years ago

#48612 closed defect (worksforme)

ghc build failed on dtrace

Reported by: J.Gilbey@… Owned by: kitchen.andy@…
Priority: Normal Milestone:
Component: ports Version: 2.3.3
Keywords: Cc: neverpanic (Clemens Lang)
Port: ghc

Description

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!

Attachments (1)

ghc.log (145.8 KB) - added by J.Gilbey@… 5 years ago.

Download all attachments as: .zip

Change History (8)

Changed 5 years ago by J.Gilbey@…

Attachment: ghc.log added

comment:1 Changed 5 years ago by 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.

comment:2 Changed 5 years ago by mf2k (Frank Schima)

Cc: cal@… added
Owner: changed from macports-tickets@… to kitchen.andy@…
Port: ghc added

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

comment:3 Changed 5 years ago by 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.

comment:4 Changed 5 years ago by 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

comment:5 Changed 5 years ago by 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?

comment:6 Changed 5 years ago by 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

comment:7 Changed 5 years ago by neverpanic (Clemens Lang)

Resolution: worksforme
Status: newclosed

Glad you got it working!

Note: See TracTickets for help on using tickets.