Created attachment 325902 [details] emerge --info and contents of emerge log file dev-util:cmake-2.8.9:20121007-081002.log After upgrading the Intel Fortran compiler to version 2013 (dev-lang/ifc-13.0.0.079-r1), I can no longer compile CMake (dev-util/cmake; update to 2.8.9(-r1), or recompile 2.8.8-r3). Emerge fails on an access violation for the directory /opt/intel/ism This happens on all three of my Gentoo systems (32 and 64 bit): -- Configuring done -- Generating done -- Build files have been written to: /var/tmp/portage/dev-util/cmake-2.8.9/work/cmake-2.8.9_build >>> Source configured. --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE "/var/log/sandbox/sandbox-10354.log" 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: mkdir S: deny P: /opt/intel/ism A: /opt/intel/ism R: /opt/intel/ism C: /opt/intel/composerxe-2013.0.079/bin/ia32/ifort -O2 -march=i686 -pipe CMakeFortranCompilerId.F F: mkdir S: deny P: /opt/intel/ism A: /opt/intel/ism R: /opt/intel/ism C: /opt/intel/composerxe-2013.0.079/bin/ia32/ifort -O2 -march=i686 -pipe -c /var/tmp/portage/dev-util/cmake-2.8.9/work/cmake-2.8.9_build/Tests/CMakeFiles/CheckFortran/CMakeFiles/CMakeTmp/testFortranCompiler.f -o CMakeFiles/cmTryCompileExec797886714.dir/testFortranCompiler.f.o F: mkdir S: deny P: /opt/intel/ism A: /opt/intel/ism R: /opt/intel/ism C: /opt/intel/composerxe-2013.0.079/bin/ia32/ifort -Wl,-O1 -Wl,--as-needed -O2 -march=i686 -pipe CMakeFiles/cmTryCompileExec797886714.dir/testFortranCompiler.f.o -o cmTryCompileExec797886714 -i_dynamic -------------------------------------------------------------------------------- >>> Failed to emerge dev-util/cmake-2.8.9, Log file: >>> '/var/log/portage/dev-util:cmake-2.8.9:20121007-081002.log' * * The following package has failed to build or install: * * (dev-util/cmake-2.8.9::gentoo, ebuild scheduled for merge), Log file: * '/var/log/portage/dev-util:cmake-2.8.9:20121007-081002.log' * Steps to reproduce: 1. emerge -vu dev-lang/ifc 2. emerge -v1 dev-util/cmake Result: Access violation Expected result: dev-util/cmake compiles and installs without problems A workaround is to unmerge ifc, update cmake and remerge ifc: 1. emerge -v --depclean dev-lang/ifc 2. emerge -vu1 dev-util/cmake 3. emerge -v dev-lang/ifc
Created attachment 325904 [details] Output of emerge --info
Created attachment 325906 [details] Output of emerge -vu dev-util/cmake
Could you execute ifc -V ? Do you have a valid license?
(In reply to comment #3) > Could you execute > ifc -V > Do you have a valid license? $ ifort -V Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.0.0.079 Build 20120731 Copyright (C) 1985-2012 Intel Corporation. All rights reserved. FOR NON-COMMERCIAL USE ONLY I've got a non-commercial licence, the compiler itself works well.
okay thanks. Then I am out. Thanks for testing.
On a related note, compiling certain packages with dev-lang/icc-13 also produces the same access violations with /opt/intel/ism. Among those are codeblocks, gimp, bzip2, libxml2 and many more. I'm using a non-commercial license $ icc -V Intel(R) C Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.0.0.079 Build 20120731 Copyright (C) 1985-2012 Intel Corporation. All rights reserved. FOR NON-COMMERCIAL USE ONLY
It seems this is related to Intel's "Software Improvement Program", which is supposed to collect usage statistics. http://software.intel.com/en-us/articles/software-improvement-program The folder is automatically generated by icc/ifc in /opt/intel/ism, prompting plenty of access violations from portage. While the data-collection is optional, folder creation happens regardless. We could try asking them to not do that, but I'm not sure if Intel intends to change that. Also see: http://software.intel.com/en-us/forums/topic/329346 How do we deal with this in Portage? Disabling the sandbox works, but is hardly a long-term solution.
Hmmm, but if the CMake-uninstall workaround works, that effect (whatever it is) should be reproducable with some patch one would think.
I just created manually the folder(s) /opt/intel/ism/rm and now the compilation of autodock_vina with icc does not complain any more. Is this OK or shouldn't I have done that? This is my first ever package compilation with icc (science overlay) after following the icc guide at gentoo-wiki. This is my icc version: # icc -V Intel(R) C Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.0 Build 20121010 Copyright (C) 1985-2012 Intel Corporation. All rights reserved. FOR NON-COMMERCIAL USE ONLY
I can confirm that manually creating an empty /opt/intel/ism/rm directory avoids this bug. It might be a valid solution to have the icc/ifc ebuilds do that during installation.
CCing maintainer who might have some idea.
Here's a patched ebuild for dev-libs/intel-common that creates that directory using keepdir: http://git.overlays.gentoo.org/gitweb/?p=user/AstroFloyd.git;a=tree;f=dev-libs/intel-common
*** This bug has been marked as a duplicate of bug 332657 ***
A dup? Bug 332657 is marked as fixed, but this bug still remains. They concern different paths aswell.
(In reply to comment #14) > A dup? Bug 332657 is marked as fixed, but this bug still remains. They > concern different paths aswell. Do you have a valid license? This does't happen if you have one.
(In reply to comment #15) > (In reply to comment #14) > > A dup? Bug 332657 is marked as fixed, but this bug still remains. They > > concern different paths aswell. > > Do you have a valid license? This does't happen if you have one. I do have a valid non-commercial license, yes. icc works fine for the most part, except for some packages such as bzip2 which trigger the sandbox violation. Manually creating the /opt/intel/ism/rm dir solves this problem completely.
(In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #14) > > > A dup? Bug 332657 is marked as fixed, but this bug still remains. They > > > concern different paths aswell. > > > > Do you have a valid license? This does't happen if you have one. > > I do have a valid non-commercial license, yes. icc works fine for the most > part, except for some packages such as bzip2 which trigger the sandbox > violation. > Manually creating the /opt/intel/ism/rm dir solves this problem completely. Could you please attach a build.log from intel-commons?
Created attachment 336572 [details] intel-common build.log (In reply to comment #17) > Could you please attach a build.log from intel-commons?
23 Jan 2013; Justin Lecher <jlec@gentoo.org> intel-sdp.eclass: + Add dummy dir to avoid sandbox violations when emerging with + FEATURES=-userpriv, #437512 +
Works. Thanks!
