Summary: | dev-lang/ifc/icc - sandbox violation in /opt/intel/ism when not using userpriv usersandbox | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Marc van der Sluys <gentoo> |
Component: | Current packages | Assignee: | Gentoo Science Related Packages <sci> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | gentoo, main.haarp, sci, urcindalo |
Priority: | Normal | ||
Version: | 10.0 | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://software.intel.com/en-us/articles/software-improvement-program | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge --info and contents of emerge log file dev-util:cmake-2.8.9:20121007-081002.log
Output of emerge --info Output of emerge -vu dev-util/cmake intel-common build.log |
Description
Marc van der Sluys
2012-10-07 12:38:31 UTC
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! |