Re: install ifort 9.0 with alien...

[Jo Shields <jo.shields@comlab.ox.ac.uk>]

Lennart Sorensen wrote:

> On Tue, Dec 13, 2005 at 08:39:10PM +0100, fred wrote:
>  
>
> > Hi all,
> >
> > I attempt to install intel fortran compiler 9.0 amd64/EM64T
> > (intel-iforte9-9.0-021.em64t.rpm) with alien.
> >
> > But alien fails :
> > alien intel-iforte9-9.0-021.em64t.rpm
> > Package build failed. Here's the log:
> > dh_testdir
> > dh_testdir
> > dh_testroot
> > dh_clean -k -d
> > dh_installdirs
> > dh_installdocs
> > dh_installchangelogs
> > find . -maxdepth 1 -mindepth 1 -not -name debian -print0 | \
> >        xargs -0 -r -i cp -a {} debian/intel-iforte9
> > dh_compress
> > dh_makeshlibs
> > objdump: debian/intel-iforte9/opt/intel/fce/9.0/lib/libcprts.so: File
> > format not recognized
> > objdump: debian/intel-iforte9/opt/intel/fce/9.0/lib/libcxa.so: File
> > format not recognized
> > objdump: debian/intel-iforte9/opt/intel/fce/9.0/lib/libcxaguard.so: File
> > format not recognized
> > objdump: debian/intel-iforte9/opt/intel/fce/9.0/lib/libifcore.so: File
> > format not recognized
> > objdump: debian/intel-iforte9/opt/intel/fce/9.0/lib/libifcoremt.so: File
> > format not recognized
> > objdump: debian/intel-iforte9/opt/intel/fce/9.0/lib/libifport.so: File
> > format not recognized
> > objdump: debian/intel-iforte9/opt/intel/fce/9.0/lib/libunwind.so: File
> > format not recognized
> > dh_installdeb
> > dh_shlibdeps
> > /usr/bin/ldd: line 1: /lib/ld-linux.so.2: No such file or directory
> > ldd: /lib/ld-linux.so.2 exited with unknown exit code (127)
> > dpkg-shlibdeps: failure: ldd on
> > `debian/intel-iforte9/opt/intel/fce/9.0/bin/codecov' gave error exit
> >                        status 1
> > dh_shlibdeps: command returned error code 256
> > make: [binary-arch] Error 1 (ignored)
> > dh_gencontrol
> > dpkg-gencontrol: error: current build architecture amd64 does not appear
> > in package's list (em64t)
> > dh_gencontrol: command returned error code 65280
> > make: *** [binary-arch] Error 1
> > find: intel-iforte9-9.0: No such file or directory
> >
> > In fact, several *.so file are ascii text :
> > cat libunwind.so
> > INPUT ( libunwind.so.5 )
> >
> > I could link these files alien would erase them.
> >
> > What's wrong ?
> >    
>
> Not sure, but redhat does organize their 64bit support rather
> differently.  Of course alien may just not know about amd64 yet.  Of
> course on redhat you have 32bit libs too, not just 64bit and some
> companies think that doing mixed 32 and 64bit code on amd64 is perfectly
> reasonable, which it isn't on a pure 64bit system like amd64 debian.
>
> /lib/ld-linux.so.2 is for 32bit systems, amd64 doesn't use that which
> makes it really look like that package requires a mixed architecture
> system (perhaps ia32-libs would help since it does contain
> /lib/ld-linux.so.2).
>
> Len Sorensen

Intel, in an impressive display of understanding of the way RPM is meant 
to be used, don't actually have much reliance on the paths inside the 
RPM - by default, they install to /opt/intel, though the 'install' 
script Intel provides will extract the RPMs to a different location, if 
asked. Either way, the files installed by the RPMs aren't usable - the 
install script then has to go through a load of the scripts in 
/foo/intel/bin/ and put the real path in.

To sort out the horrendous not-distro-agnostic approach Intel take, as 
well as the refusal of the installer to skip the license file step (and 
use a license server), we wrote a few scripts at work which take a 
.tar.gz from Intel's download area, and repackage all the (RPM) contents 
as .tar.gz, with a replacement installation script (then make a .iso 
from the result).

--Jo Shields