VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: open_wr S: deny ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.0_20170731-194316 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-6.3.0 * Available Python interpreters, in order of preference: [1] python3.4 [2] python3.5 (fallback) [3] python2.7 (fallback) Available Ruby profiles: [1] ruby21 (with Rubygems) * [2] ruby22 (with Rubygems) emerge -qpv dev-util/coccinelle [ebuild N ] dev-util/coccinelle-1.0.6 USE="ocamlopt pcre -doc -emacs -ocaml -python {-test} -vim-syntax" PYTHON_TARGETS="python2_7"
Created attachment 487730 [details] emerge-info.txt
Created attachment 487732 [details] dev-util:coccinelle-1.0.6:20170802-165318.log
Created attachment 487734 [details] emerge-history.txt
Created attachment 487736 [details] environment
Created attachment 487738 [details] etc.portage.tbz2
Created attachment 487740 [details] logs.tbz2
Created attachment 487742 [details] sandbox-10062.log
Created attachment 487744 [details] temp.tbz2
*** Bug 626904 has been marked as a duplicate of this bug. ***
I can confirm this on my system - for anyone else landing here looking for a workaround - setting USE=-pcre will avoid the issue. [ebuild R ] dev-util/coccinelle-1.0.6::gentoo USE="ocamlopt python vim-syntax -doc -emacs -ocaml -pcre* {-test}" PYTHON_TARGETS="python2_7" 0 KiB
Thanks, Malcolm, for the workaround. It looks like the Makefile might be trying to compile ocaml's pcre.mli and thus replace pcre.cmi: make[5]: Entering directory '/var/tmp/portage/dev-util/coccinelle-1.0.6/work/coccinelle-1.0.6/globals' /usr/bin/ocamlopt.opt -unsafe -I ../commons -I /usr/lib64/ocaml/pcre -c config.ml /usr/bin/ocamlopt.opt -unsafe -I ../commons -I /usr/lib64/ocaml/pcre -c flag.ml /usr/bin/ocamlc.opt -unsafe -I ../commons -I /usr/lib64/ocaml/pcre -c iteration.mli /usr/bin/ocamlc.opt -unsafe -I ../commons -I /usr/lib64/ocaml/pcre -c /usr/lib64/ocaml/pcre/pcre.mli * ACCESS DENIED: open_wr: /usr/lib64/ocaml/pcre/pcre.cmi File "/usr/lib64/ocaml/pcre/pcre.mli", line 1: Error: I/O error: /usr/lib64/ocaml/pcre/pcre.cmi: Permission denied Note the last command was on pcre.mli, while all the others were on files within coccinelle's globals directory.
Within the Makefile, it generates ".depend" file with: /usr/bin/ocamldep -I ../commons -I /usr/lib64/ocaml/pcre *.mli *.ml > .depend This generates the following dependency: > regexp_pcre.cmo : /usr/lib64/ocaml/pcre/pcre.cmi > regexp_pcre.cmx : /usr/lib64/ocaml/pcre/pcre.cmi While we have /usr/lib64/ocaml/pcre/pcre.cmi from dev-ml/pcre-ocaml, due to the order of installation and a rule in coccinelle/globals/Makefile (.mli.cmi), "make" try to re-generate "pcre.cmi" from "/usr/.../pcre.mli". Thanks to the ebuild dependency, we are sure that "/usr/.../pcre.cmi" exists. So we can safely filter out the dep to "/usr/.../pcre.cmi" using e.g. "sed 's!/.*/pcre.cmi!!'" and make the process won't touch the file. ... or more sophisticated solution would be separating local vs global dependency as in this commit: https://github.com/coccinelle/coccinelle/commit/984eba5c98b0ac2fdc7f13b059837a6328c56697
Created attachment 523912 [details, diff] coccinelle_pcre.patch I've made a patch based on the one linked to in comment 12. I haven't verified that it didn't break any functionality, but it does allow for compilation to proceed and finish.
package removed.
