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)
Change History (14)
Changed 8 years ago by RJVB (René Bertin)
comment:1 Changed 8 years ago by mf2k (Frank Schima)
Cc: | kimuraw@… removed |
---|---|
Owner: | set to kimuraw |
Status: | new → assigned |
comment:2 Changed 8 years ago by kimuraw (kimura wataru)
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)
generated probes.h file. It seems to be reproducible on my end.
comment:4 follow-up: 5 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 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 follow-up: 7 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 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: | assigned → closed |
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.