ruby23 fails to build on 10.9.5 (:info:build error: unable to open output file '/dev/fd/8': '')

[RJVB (René Bertin)]

Trying to build port:ruby23 from source I get the following error:

> sudo port -sv install ruby23
...
:info:build    CC = /usr/bin/clang
:info:build    LD = ld
:info:build    LDSHARED = /usr/bin/clang -dynamiclib
:info:build    CFLAGS = -Os -fno-common -pipe -arch x86_64
:info:build    XCFLAGS = -D_FORTIFY_SOURCE=2 -fstack-protector -fno-strict-overflow -fvisibility=hidden -DRUBY_EXPORT
:info:build    CPPFLAGS = -I/opt/local/include -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -D_DARWIN_UNLIMITED_SELECT -D_REENTRANT   -I. -I.ext/include/x86_64-darwin13 -I./include -I.
:info:build    DLDFLAGS = -Wl,-undefined,dynamic_lookup -Wl,-multiply_defined,suppress -L/opt/local/lib -install_name /opt/local/lib/libruby.2.3.0.dylib -current_version 2.3.0 -compatibility_version 2.3.3  -fstack-protector -Wl,-u,_objc_msgSend -framework CoreFoundation  -fstack-protector -Wl,-u,_objc_msgSend -framework CoreFoundation  -arch x86_64
:info:build    SOLIBS = -lpthread -ldl -lobjc
:info:build Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
:info:build Target: x86_64-apple-darwin13.4.0
:info:build Thread model: posix
:info:build translating probes probes.d
:info:build error: unable to open output file '/dev/fd/8': ''
:info:build 1 error generated.
:info:build dtrace: failed to compile script probes.d: Preprocessor failed to process input program
:info:build make: *** [probes.h] Error 1
...

[kimuraw (kimura wataru)]

I cannot reproduce the build error on my Mac (OS X 10.9.5 / VMWare fusion). But I found a similar problem for ruby-2.1.3.

• ​https://github.com/Homebrew/legacy-homebrew/issues/32910

The article says wrong permission of /usr/sbin/dtrace leads build errors of ruby.

Maybe, the following operation solves your problem.

$ sudo chmod -s /usr/sbin/dtrace
$ sudo port clean ruby23
$ sudo port -sv install ruby23

[RJVB (René Bertin)]

Yes, this looks like a permissions problem calling dtrace. Rather than making dtrace SUID root it would probably be cleaner to figure out how to make MacPorts build it as root.

The big question here is why ruby needs to do this, and to what extent the file generated with the command is host-specific. If it's not, the cleanest thing would be to distribute if in ${filespath} and copy it to the appropriate location in the post-configure.

This is what you get running sudo make in ${worksrcpath}:

...
dtrace -o probes.h.tmp -h -C -I. -I.ext/include/x86_64-darwin13 -I./include -I. -s probes.d
. ./vm_opts.h
sed -e 's/RUBY_/RUBY_DTRACE_/g' -e 's/PROBES_H_TMP/RUBY_PROBES_H/' -e 's/(char \*/(const char */g' -e 's/, char \*/, const char */g' probes.h.tmp > probes.h
rm -f probes.h.tmp
...

I'll see what probes.h contains and attach it if it seems redistributable.

[RJVB (René Bertin)]

generated probes.h file. It seems to be reproducible on my end.

[geekosaur]

dtrace isn't normally suid. If kimuraw's instruction worked, it turned suid *off* (chmod -s); presumably you caused the problem by making dtrace suid yourself. (Yes, that is sometimes convenient; it's also quite the security hole, and also breaks non-tracing use cases like this one where you're just compiling a D script: since it doesn't know it is suid, the file is written owned by root instead of the user running it.)

[RJVB (René Bertin)]

Replying to geekosaur:

(Yes, that is sometimes convenient; it's also quite the security hole,

I know, but isn't it a bit more than just a convenience if you want to use dtrace or something built on top of it?

and also breaks non-tracing use cases like this one where you're just compiling a D script: since it doesn't know it is suid, the file is written owned by root instead of the user running it.)

That shouldn't be a problem here as long as it's world-readable, but the error cited above is not about permissions on the probes.h file. It's hard to know though who complains about opening /dev/fd/8 (an inter-process pipe?) for output, though. It turns out you were right, but I fail to see why.

I think it would still be interesting to know if a pre-generated probes.h can be used.

[kimuraw (kimura wataru)]

Thanks geekosaur. From your suggestion, I confirmed suid bit of dtrace in my Mac is *off*.

sudo port commands work under user "macports" privileges by default. That is strange dtrace requires "root" suid in this problem.

RJVB, can you show me permissions of the build directories and its filesystem?

$ ls -lad /Volumes/VMs/MPbuild /Volumes/VMs
$ mount | grep VMs

[kimuraw (kimura wataru)]

build success main.log without giving suid to dtrace

[kimuraw (kimura wataru)]

build success probes.h, same as RJVB's

[RJVB (René Bertin)]

Replying to kimuraw:

sudo port commands work under user "macports" privileges by default. That is strange dtrace requires "root" suid in this problem.

No, my analysis was wrong:

• running sudo make inside ${worksrcpath} (and with the environment set as port would set it) works fine, whether dtrace is SUID or not
• running port build ruby23 works fine when dtrace is NOT suid root.

The problem has to do with write permissions on a special file which I *think* is an inter-process pipe where the "stdin part" is created by a privileged application (dtrace running SUID root) and a non privileged process. I've never seen this before, but without knowing who owns /dev/fd/8 (file descriptor 8) I cannot say more.

@kimuraw: do you have a possibility to compare the generated probes.h file with mine, preferably also when using other Mac OS versions? It it's identical everywhere (= it depends only on the probes.d input file) then it isn't necessary to generate it anew each time.

[kencu (Ken)]

could you just delete -pipe from this build?

:build    CFLAGS = -Os -fno-common -pipe -arch x86_64

I understand it just improves performance, but it is not a required flag, I believe...

[RJVB (René Bertin)]

• I *think* -pipe is moot with clang, at least that compiler doesn't seem to invoke the different compilation stages as separate processes
• whether or not -pipe improves performance depends on how parallel you build, and how loaded the host already is...