Opened 8 years ago

Closed 4 years ago

#53045 closed defect (worksforme)

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

Reported by: RJVB (René Bertin) Owned by: kimuraw (kimura wataru)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc:
Port: ruby23

Description

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
...

Attachments (4)

main.log (39.6 KB) - added by RJVB (René Bertin) 8 years ago.
probes.h (16.2 KB) - added by RJVB (René Bertin) 8 years ago.
generated probes.h file. It seems to be reproducible on my end.
ruby23-10.9-clang-main.log (96.0 KB) - added by kimuraw (kimura wataru) 8 years ago.
build success main.log without giving suid to dtrace
ruby23-10.9-probes.h (16.2 KB) - added by kimuraw (kimura wataru) 8 years ago.
build success probes.h, same as RJVB's

Download all attachments as: .zip

Change History (14)

Changed 8 years ago by RJVB (René Bertin)

Attachment: main.log added

comment:1 Changed 8 years ago by mf2k (Frank Schima)

Cc: kimuraw@… removed
Owner: set to kimuraw
Status: newassigned

comment:2 Changed 8 years ago by 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.

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

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

Changed 8 years ago by RJVB (René Bertin)

Attachment: probes.h added

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

comment:4 Changed 8 years ago by 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.)

comment:5 in reply to:  4 Changed 8 years ago by 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.

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

Changed 8 years ago by kimuraw (kimura wataru)

Attachment: ruby23-10.9-clang-main.log added

build success main.log without giving suid to dtrace

Changed 8 years ago by kimuraw (kimura wataru)

Attachment: ruby23-10.9-probes.h added

build success probes.h, same as RJVB's

comment:7 in reply to:  6 Changed 8 years ago by 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.

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

comment:9 Changed 8 years ago by 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...

comment:10 Changed 4 years ago by kimuraw (kimura wataru)

Resolution: worksforme
Status: assignedclosed
Note: See TracTickets for help on using tickets.