Intel has released a new icc/icpc compiler version 11.0.069 Reproducible: Always Steps to Reproduce:
Created attachment 171758 [details] dev-lang/icc-11.0.069 I update old ebuild for Intel compiler new version also I tested. It works fine. regards, b3hzat.
I used it under amd64, but it does not work. I think the most possible problem is the rpm directory name, instead of "data", is now "l_cproc_p_11.0.069". (In reply to comment #1) > Created an attachment (id=171758) [edit] > dev-lang/icc-11.0.069 > > I update old ebuild for Intel compiler new version also I tested. It works > fine. > regards, > b3hzat. >
Created attachment 172919 [details] dev-lang/icc-11.0.074 Hello everyone, Compiler version is updated with icc-11.0.074. Release Notes: http://registrationcenter-download.intel.com/irc_nas/1309/l_cproc_p_11.0.074_README.txt
(In reply to comment #2) > I used it under amd64, but it does not work. > I think the most possible problem is the rpm directory name, instead of "data", > is now "l_cproc_p_11.0.069". > (In reply to comment #1) > > Created an attachment (id=171758) [edit] > > dev-lang/icc-11.0.069 > > > > I update old ebuild for Intel compiler new version also I tested. It works > > fine. > > regards, > > b3hzat. > > > Hello inter, What's your problem? Are you can not download or compiled? Wich one do you have ? Regards, b3hzat.
Created attachment 173064 [details] Bug fixed.
anybody tried idb ? with the new version, b3hzat ?
(In reply to comment #6) > anybody tried idb ? with the new version, b3hzat ? > Hello Anders, I can not try yet. Regards, Behzat.
Created attachment 173250 [details] Sorry for confision. This is final version. I forgot environment variable. Sorry for flood. Regards, Behzat.
Created attachment 173252 [details] Final v2. Please delete other ebuild files. I am really sorry for flood. Regards, Behzat.
Created attachment 173253 [details] Final v3. I am really absent minded today and sorry for my all flood. Could you delete all ebuild files except last one ? Regards, Behzat.
Created attachment 173264 [details] Fixed for dev-lang/idb-10.1.018 support. Now work with dev-lang/idb-10.1.018.
I can confirm that the latest ebuild works on amd64. But I've trouble using ICC with portages sandbox-feature enabled - seems like icc is doing weird stuff in /usr/local/share/macrovision. Trying to compile bzip2 with ICC I got a sandbox access violation, the related log repeatedly list those lines: open_wr: /usr/local/share/macrovision/storage/FLEXnet/INTEL_00211300_event.log open_wr: /usr/local/share/macrovision/storage/FLEXnet/INTEL_00211300_tsf.data With FEATURES="-sandbox" emerge -1 bzip2 everything works fine.
Hi all, Thanks for your work. I will try to look at the compiler when I find more time. This time Intel included all icc,idb,mkl,ipp,tbb within one big file so it might need more work. If you still want to work on this ebuild, try to work it from the most recent in the tree, which also includes some amd64 fixes (though I have not testes yet if they are still needed).
Ebuild icc-11.0.074 does not finish installing after >10hrs, I get a lot of the following messages scrolling on the screen the entire time (1 message every ~1sec): * !WX --- --- opt/intel/Compiler/11.0/074/mkl/lib/em64t/libmkl_solver_lp64.a:def_mpz_tdiv_qr.o
> * !WX --- --- > opt/intel/Compiler/11.0/074/mkl/lib/em64t/libmkl_solver_lp64.a:def_mpz_tdiv_qr.o This probably needs to add RESTRICT="binchecks" in the ebuild since icc blobs are quite large.
(In reply to comment #15) > This probably needs to add RESTRICT="binchecks" in the ebuild since icc blobs > are quite large. > > Still seeing the issue: $ RESTRICT="binchecks" emerge icc .... * QA Notice: The following files contain executable stacks * Files with executable stacks will not work properly (or at all!) * on some architectures/operating systems. A bug should be filed * at http://bugs.gentoo.org/ to make sure the file is fixed. * For more information, see http://hardened.gentoo.org/gnu-stack.xml * Please include the following list of files in your report: * !WX --- --- opt/intel/Compiler/11.0/074/mkl/lib/em64t/libmkl_solver_lp64.a:def_umul_ppmm.o * !WX --- --- opt/intel/Compiler/11.0/074/mkl/lib/em64t/libmkl_solver_lp64.a:def_udiv_qrnnd_preinv.o .....
Looks like version 11.0.081 has been released.
Created attachment 182044 [details] icc-10.0.074.ebuild without idb, ipp, mkl This ebuild removes the ipp and mkl packages from installation, as they are provided by Portage already. This fixes the 30 hour installation time. Also, the check for icc < v9 is wrong. It only checks if the version installed is older than what we're installing. Once icc is installed, it causes sandbox violations if used with portage. For instance, when compiling bzip2 > icc -O3 -ip -xP -gcc -Wall -Winline -D_FILE_OFFSET_BITS=64 -Wl,-O1 -o bzip2recover bzip2recover.o > ACCESS DENIED open_wr: /usr/local/share/macrovision/storage/FLEXnet/INTEL_00211300_tsf.data > ACCESS DENIED open_wr: /usr/local/share/macrovision/storage/FLEXnet/INTEL_00211300_event.log I'll investigate more.
Using FEATURES="-sandbox" you can compile with Portage, but it looks like icc-11 does some bad things. > * QA Notice: The following files contain executable stacks > * Files with executable stacks will not work properly (or at all!) > * on some architectures/operating systems. A bug should be filed > * at http://bugs.gentoo.org/ to make sure the file is fixed. > * For more information, see http://hardened.gentoo.org/gnu-stack.xml > * Please include the following list of files in your report: > * RWX --- --- usr/bin/bzip2recover > * !WX --- --- usr/lib64/libbz2.a:blocksort.o > * !WX --- --- usr/lib64/libbz2.a:huffman.o > * !WX --- --- usr/lib64/libbz2.a:crctable.o > * !WX --- --- usr/lib64/libbz2.a:randtable.o > * !WX --- --- usr/lib64/libbz2.a:compress.o > * !WX --- --- usr/lib64/libbz2.a:decompress.o > * !WX --- --- usr/lib64/libbz2.a:bzlib.o > * RWX --- --- bin/bzip2
(In reply to comment #19) Recently I found that upgrading dev-python/numpy from 1.2.1 to 1.3.0 was failing because of the version (11.0.081) of the Intel fortran compiler I had on my systems. Un-merging ifc allowed the numpy upgrade to succeed, using GNU fortran. This was not a numpy issue as such but served once again to highlight the various issues that have been raised in this bug about the 11.0 series of the Intel compilers. The point in making these comments now is to note that a new build (20090318) of the 11.0 compilers is available as 11.0.083. As far as I can see, the sandbox problems referred to in #18 are fixed but the executable stack issues of #19 remain. It would be nice to know where this application is going in gentoo as there is not that much obvious activity. Clearly it would be good to have ebuilds for 11.0.083 for icc, ifc, and idb in portage. If it would help I could probably tidy up my local overlay ebuilds and post them but they're probably not much different from those already available via this bug for slightly earlier versions. (As an aside I'm wondering whether icc, etc. have a non-specialist role on linux - so many applications fail to compile, particularly the multi-media stuff that could benefit from Intel's own compiler optimizations for their own processors.)
Hi all. Noone has posted an ebuild for icc-11.0.083 yet so I'll go ahead and post mine. It emerges successfully and after emerging I was able to use icc-11.0.083 to compile dev-libs/glib and x11-libs/gtk+. I have not fetch tested this ebuild, but I did do a pretty thorough comparison between the relevant parts of this ebuild and another ebuild I had adapted for icc-ll.0.083 that I knew fetched the sources properly (that one was based on one of the previous icc ebuilds where idb and other things were all installed with icc. This one is adapted from the latest 11.0.074 posted by mattst88 which had been improperly labeled as 10.0.074). Fetch Should work in this version, please let me know if it does not. I can confirm no sandbox problems with this version, but if you emerge something with it you will get QA notices about text relocations and executable stacks. I added some code to this ebuild that sets up the paths for ia64. I don't know why this was left out of previous ebuilds and I don't have an ia64 machine, so ia64 users, let me know if you have any problems. I'd like to see this version bump go into portage soon, so please everyone test it and make sure it works. We especially need ia64 and amd64 users to test, I only have x86 machines to test on. Also, anyone who can look over the ebuild and make sure it's doing everything the way it's supposed to, please do so.
Created attachment 190551 [details] /usr/local/portage/dev-lang/icc/icc-11.0.083.ebuild icc-11.0.083
I've tested the latest ebuild (11.0.083) on amd64. Despite the QA notice (executable stacks) everything seems to work. Thank you for the ebuild. I'd like to suggest using SRC_URI arrows for dev-lang/icc, dev-lang/idb, sci-libs/ipp and sci-libs/mkl (and dev-lang/ifc ?). That way intels stupid packaging is less annoying.
In an attempt to figure out what's going on with the executable stacks, I posted on Intel's forum. http://software.intel.com/en-us/forums/intel-c-compiler/topic/65611/
I have rewritten the ebuild and committed icc-11.1.046 to the tree for ~amd64 and ~x86. Please test and report any problems.
Once this package gets a bit of testing, we can make a full suite of icc/ifc/idb/mkl/ipp/tbb ebuilds to go with it.
(In reply to comment #25) > I have rewritten the ebuild and committed icc-11.1.046 to the tree for ~amd64 > and ~x86. Please test and report any problems. > Thanks - just trying it out. /etc/profile.d/icc.sh doesn't seem to work for me - I needed to create a suitable /etc/env.d/05icc or things compiled with icc couldn't find the icc shared libs.
I haven't had a chance to test the new ebuilds, so: Does the latest version still exhibit the sandbox violations mentioned in comment #12, or the executable stacks problem mentioned in comment #19?
I've just committed revision -r2 which fixes the environment variable problems. However bug 282146 is fixed for amd64 only so I'm not keywording ~x86 until I can find a fix there. The sandbox violations are gone. The executable stacks are still there but I couldn't find any issues with programs for which those warnings are produced.
Sempron # emerge icc -vp These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] dev-libs/beecrypt-4.1.2-r1 USE="java python threads -nocxx" 757 kB [ebuild N ] app-arch/rpm-4.4.6-r6 USE="nls perl python sqlite -doc" 16,756 kB [ebuild U ] dev-lang/icc-11.1.046-r2 [10.1.018] 1,320,264 kB Total: 3 packages (1 upgrade, 2 new), Size of downloads: 1,337,776 kB 1.3 GB?! I remember it does something silly like packing idb,ipp,mkl in, it's there anyway we can prevent having to download all this?
I'm still needing to add a LDPATH line to /etc/env.d/05icc file, otherwise code compiled with icc is unable to find the icc libraries.
Created attachment 205789 [details] icc-11.1.056.ebuild New version of icc. I've added LDPATH to 05icc env file. Could someone make ebuild for idb-11*??
Created attachment 205793 [details] icc-11.1.056.ebuild Sorry the old one had wrong dir in env ("em64t" changed to "intel64")
Created attachment 205890 [details, diff] Patch to create link from icc to eclipse I don't know if this works, but it might be useful
Created attachment 205972 [details, diff] Patch to create link from icc to eclipse Added option to delete eclipse support when there isn't eclipse use flag
Created attachment 205973 [details] idb-11.1.056.ebuild It is also with eclipse support
Bumped to 11.0.56 with eclipse plugin and rewritten ebuild. Thanks.
