Installation issues ifort 11.0.074 ia32

[e745200]

I am trying to install the Intel Fortran Compiler version 11 from l_cprof_p_11.0.074_ia32.tgz .

When I try a "non-root" installation the installation procedure aborts:

$ ./install.sh
Please make your selection by entering an option.
...(snip)...
3. Install as current user to limit access to user level
...(snip)...
Please type a selection [1]: 3
...(clear)...
--------------------------------------------------------------------------------
Initializing, please wait...
--------------------------------------------------------------------------------
./install.sh: line 427: 9558 Segmentation fault $pset_engine_binary --log-file=$log_file $silent
_params $duplicate_params $params --PACKAGE_DIR=$fullpath

A root installation performs fine, but then is the compiler that does not work :

$ cd /opt/intel/Compiler/11.0/074/bin/ia32
$ ./ifort
Segmentation fault

The environment is as follows :

$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel Xeon CPU 3.00GHz
stepping : 10
cpu MHz : 3000.098
cache size : 2048 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu tsc msr pae mce cx8 apic mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constan
t_tsc up pni monitor ds_cpl cid cx16 xtpr lahf_lm
bogomips : 7503.70

processor : 1
(same as for processor 0)

$ uname -a
Linux 2.6.18-53.el5xen #1 SMP Wed Oct 10 17:06:12 EDT 2007 i686 i686 i386 GNU/Linux

It is a virtualized environment (through xen) on which the previous version of the compiler works fine.

Any clue ?

Further info:

Actually, the behavior mentioned above happens if I try to run the compiler as a non-root user.

Running it as root it works (at least it starts, further checks will follow).

Is this the intended behavior ? I do not think so.

A friend of mine (on a simpler environment: no virtualization, single processor) made a similar installation and the compiler can be run using a regular user account.

How can I get the same behaviour ?

( And, however, it remains the fact that I cannot perform a non-root installation ! ).

[e745200]

Do I need a "root and RPM-using" installation ?

[e745200]

Quoting - e745200

Do I need a "root and RPM-using" installation ?

Well, I did it, but, again, I cannot run the compiler as a standard user.

Any clue ??

[Ron_Green]

It's odd, for sure.

If root is OK with the compiler install and running, then perhaps it's a permissions problem. As a regular user, can you do these:

ls /tmp

touch /tmp/foo

And if that works OK without permission problems, I'd check the directory permisions all up and down the tree from /opt down to /opt/intel/Compiler/11.0/074/lib/* and ../bin/*

I installed our lab systems here as non-root user and I don't see anything like what you are seeing. But then, I also don't use Xen.

ron

[TimP]

Quoting - e745200

Well, I did it, but, again, I cannot run the compiler as a standard user.

Does your installation disallow full read and execute permissions in directories owned by root, or does /opt (if you installed there)not have the usual permissions? This is not normal.

[e745200]

Quoting - Ronald Green (Intel)

It's odd, for sure.

If root is OK with the compiler install and running, then perhaps it's a permissions problem. As a regular user, can you do these:

ls /tmp
touch /tmp/foo

And if that works OK without permission problems, I'd check the directory permisions all up and down the tree from /opt down to /opt/intel/Compiler/11.0/074/lib/* and ../bin/*

I installed our lab systems here as non-root user and I don't see anything like what you are seeing. But then, I also don't use Xen.

ron

Quoting - tim18

Does your installation disallow full read and execute permissions in directories owned by root, or does /opt (if you installed there) not have the usual permissions? This is not normal.

Thanks for your suggestions.

After having checked all the directories permissions, having uninstalled an reinstalled the suite several times with different options and kind of license files ( non commercial - trial ) ... then I realized that this odd behavior was "simply" due to the fact that in my standard-user $HOME/.bash_profile I still had the libpath of the previous version 10 included in the definition of LD_LIBRARY_PATH !!!

Then, the Segmentation faults were due to some incompatibility with the old libraries.

Once fixed the LD_LIBRARY_PATH definition and restarted the shell, both the user-installation script and the root-installed-compiler seems to work fine when run by the standard user...

In the end, it would be useful to have a WARNING about this case in the installation instruction, such as:

- Before installing this version, uninstall any previous version, or at least verify that no environmental variable refers to them.

Such a hint would make the dummy installers like me check better the operating environment ...

Thanks again !

[Steven_L_Intel1]

We don't want to instruct users to remove old versions, as we explicitly support having multiple versions installed. I'm not sure what we could say regarding user-added definitions to login scripts.

[e745200]

Quoting - Steve Lionel (Intel)

We don't want to instruct users to remove old versions, as we explicitly support having multiple versions installed. I'm not sure what we could say regarding user-added definitions to login scripts.

You are right, it was completely my fault. I just forgot that environmental customization.

I like having multiple version installed for a long-enough "parallel" span of time.

But then some problems may occur when running programs dinamically linked with the intel libraries. That is why I defined LD_LIBRARY_PATH including the intel/lib directory.

Perhaps, in these cases, it would be better having it defined in a specific script driving each application than in a profile scripts.

[TimP]

Quoting - e745200

But then some problems may occur when running programs dinamically linked with the intel libraries. That is why I defined LD_LIBRARY_PATH including the intel/lib directory.

Perhaps, in these cases, it would be better having it defined in a specific script driving each application than in a profile scripts.

The reason for supplying separate scripts with each version of Intel compilers is to avoid adverse interactions between compiler installations other than those set up by the owner of the installation. I find it difficult enough, on Windows, to avoid cluttering the initial PATHs with multiple software versions.

I just tried to build a public application with a Makefile which contains options specific to Intel compilers of 3 years ago; on top of that, it assumes addition of symlinks inside /opt/intel which have to be inferred by reading the Makefile. I've seen variations on this elsewhere. I vote against this approach.