Ebuild script for the Intel fortran compiler 7.0, set up to produce native 32-bit binaries on a AMD64 system with 32-bit emulation libraries. This fix follows the example given by pmacinnis in the Intel software forums. The Intel compiler is told to use a modified linker script that adapts the library paths (/lib -> /lib32, ...) before calling the original ld. The ebuild uses architecture dependent if-statements (if [ `use amd64` ]; then) of which I'm not sure whether they are good Gentoo style. The modified linker script is placed in /opt/intel/bin. /opt/intel/compiler70/ia32/bin would be a better place but cannot be used because one doesn't want to have this script in the PATH. This should also be straightforward to use for other versions of icc. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 34350 [details] Ebuild
Created attachment 34351 [details] modified linker script
Created attachment 34352 [details] environment variable definitions
well, i'm against this solution. Intel has already a beta version of a native i[c,f]c for IA32-EM64T (a.k.a iAMD64 ;-) ). We will put that version into portage as soon as it is available. Further, the icc ebuild is meant to provide a compiler that you can use with portage. (There are several ebuilds with icc USE-flags, yet use.mask'ed atm...) If you want or need to use i[c,f]c for IA32 on amd64, i'd suggest to use a 32bit chroot and compile anything there. Tobias: However, this ebuild you submitted is quite cool. There are errors, but using that script was a good idea. I'll discuss implementing a kind of multilib setup for the intel compilers with the rest of the team.
I guess we can wait quite a while until there's reasonable stable version of ifc/icc for IA32-EM64T, but I agree, this ebuild is too much of a dirty hack to enter the official portage tree. Anybody who's interested in this solution can get it here.
*** Bug 55100 has been marked as a duplicate of this bug. ***