Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 437512 - dev-lang/ifc/icc - sandbox violation in /opt/intel/ism when not using userpriv usersandbox
Summary: dev-lang/ifc/icc - sandbox violation in /opt/intel/ism when not using userpri...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Science Related Packages
URL: http://software.intel.com/en-us/artic...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-07 12:38 UTC by AstroFloyd
Modified: 2013-01-23 20:36 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info and contents of emerge log file dev-util:cmake-2.8.9:20121007-081002.log (dev-util_cmake-2.8.9_bugreport.txt,48.41 KB, text/plain)
2012-10-07 12:38 UTC, AstroFloyd
Details
Output of emerge --info (emerge--info.txt,5.27 KB, text/plain)
2012-10-07 12:41 UTC, AstroFloyd
Details
Output of emerge -vu dev-util/cmake (dev-util:cmake-2.8.9:20121007-081002.log,43.14 KB, text/plain)
2012-10-07 12:42 UTC, AstroFloyd
Details
intel-common build.log (build.log,157.66 KB, text/plain)
2013-01-23 10:35 UTC, haarp
Details

Note You need to log in before you can comment on or make changes to this bug.
Description AstroFloyd 2012-10-07 12:38:31 UTC
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
Comment 1 AstroFloyd 2012-10-07 12:41:59 UTC
Created attachment 325904 [details]
Output of emerge --info
Comment 2 AstroFloyd 2012-10-07 12:42:43 UTC
Created attachment 325906 [details]
Output of emerge -vu dev-util/cmake
Comment 3 Justin Lecher gentoo-dev 2012-11-22 19:06:49 UTC
Could you execute 
ifc -V
?

Do you have a valid license?
Comment 4 AstroFloyd 2012-11-22 19:20:05 UTC
(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.
Comment 5 Justin Lecher gentoo-dev 2012-11-22 19:27:54 UTC
okay thanks. Then I am out. Thanks for testing.
Comment 6 haarp 2012-12-02 13:59:48 UTC
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
Comment 7 haarp 2012-12-02 17:19:13 UTC
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.
Comment 8 AstroFloyd 2012-12-04 09:25:28 UTC
Hmmm, but if the CMake-uninstall workaround works, that effect (whatever it is) should be reproducable with some patch one would think.
Comment 9 urcindalo 2012-12-04 13:19:48 UTC
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
Comment 10 haarp 2012-12-06 22:14:40 UTC
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.
Comment 11 Michael Palimaka (kensington) gentoo-dev 2013-01-08 14:30:52 UTC
CCing maintainer who might have some idea.
Comment 12 AstroFloyd 2013-01-14 19:52:39 UTC
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
Comment 13 Justin Lecher gentoo-dev 2013-01-20 08:08:03 UTC

*** This bug has been marked as a duplicate of bug 332657 ***
Comment 14 haarp 2013-01-20 09:36:35 UTC
A dup? Bug 332657 is marked as fixed, but this bug still remains. They concern different paths aswell.
Comment 15 Justin Lecher gentoo-dev 2013-01-20 10:02:01 UTC
(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.
Comment 16 haarp 2013-01-20 10:05:49 UTC
(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.
Comment 17 Justin Lecher gentoo-dev 2013-01-23 10:24:52 UTC
(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?
Comment 18 haarp 2013-01-23 10:35:20 UTC
Created attachment 336572 [details]
intel-common build.log

(In reply to comment #17)

> Could you please attach a build.log from intel-commons?
Comment 19 Justin Lecher gentoo-dev 2013-01-23 11:14:50 UTC
   23 Jan 2013; Justin Lecher <jlec@gentoo.org> intel-sdp.eclass:
+  Add dummy dir to avoid sandbox violations when emerging with
+  FEATURES=-userpriv, #437512
+
Comment 20 haarp 2013-01-23 20:36:41 UTC
Works. Thanks!