Error:#11025 and #10014 in linux

[Lee_A_]

My system is fedora 19 , the version is :

Linux version 3.14.27-100.fc19.x86_64 (mockbuild@bkernel02.phx2.fedoraproject.org) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC) ) #1 SMP Wed Dec 17 19:36:34 UTC 2014

The ifort is parallel_studio_xe2016 for students, when inpit ''ifort --version'' in the terminal,there is :

ifort (IFORT) 16.0.0 20150815
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

When compile a file with 'ifort 't.f95'(could be compiled with g95),there is :

ipo: error #11025: Linker command line is badly formed
ifort: error #10014: problem during multi-file optimization compilation (code 1)

If input 'ifot',there is :

ifort: command line error: no files specified; for help type "ifort -help"

Then I try to use 't.f90',input 'ifort t.f90 -o a.e',there is :

fortcom: Severe: No such file or directory

... file is 'daalvars.csh*'
compilation aborted for t.f90 (code 1).

That's all information I get.

Thank you for your help!

[Kevin_D_Intel]

You can use the -Tf  (https://software.intel.com/en-us/node/579646) to enable use of the.f95 extension. As noted in the options’ discussion, it assumes the file specified uses fixed source form; thus, you may also need to specify -free. (e.g. ifort -free -Tf t.f95 )

Steve has noted a few times in our forums that the .f95 extension is a non-standard file-type for free form and recommends renaming to a more widely accepted .f90 extension.

I do not understand the issue with daalvars.csh file. I can’t reproduce this. I don’t know whether it is a coincidence that happens to match a filename related to the DAAL library, I suspect not. I doubt your source file makes any reference to that file so it seems something is not setup fully or correctly with either your environment or compiler installation. Just to eliminate the possibility, can you show us the contents of t.f90 (or t.f95 as you please)?

Also, can you show us the results of this command:  which ifort

[Lee_A_]

Kevin Davis (Intel) wrote:

You can use the -Tf  (https://software.intel.com/en-us/node/579646) to enable use of the.f95 extension. As noted in the options’ discussion, it assumes the file specified uses fixed source form; thus, you may also need to specify -free. (e.g. ifort -free -Tf t.f95 )

Steve has noted a few times in our forums that the .f95 extension is a non-standard file-type for free form and recommends renaming to a more widely accepted .f90 extension.

I do not understand the issue with daalvars.csh file. I can’t reproduce this. I don’t know whether it is a coincidence that happens to match a filename related to the DAAL library, I suspect not. I doubt your source file makes any reference to that file so it seems something is not setup fully or correctly with either your environment or compiler installation. Just to eliminate the possibility, can you show us the contents of t.f90 (or t.f95 as you please)?

Also, can you show us the results of this command:  which ifort

I check my installation.

It seems that the Compatibility in my fedora and ifort is wrong.I think I should update my fedora....

Thank you for your help!

[Kevin_D_Intel]

Yes, we do stipulate Fedora 21 and 22 in our PSXE 2016 RNs but I don't know whether that might be the issue. You could consider uninstalling/re-installing PSXE 2016 again before taking the leap to upgrade the OS.

[Lee_A_]

Kevin Davis (Intel) wrote:

Yes, we do stipulate Fedora 21 and 22 in our PSXE 2016 RNs but I don't know whether that might be the issue. You could consider uninstalling/re-installing PSXE 2016 again before taking the leap to upgrade the OS.

Now I update to fedora 22.

When I use ' ifort -free -Tf t.f95',there is :

fortcom: Severe: No such file or directory

... file is 'daalvars.csh*'
compilation aborted for t_distribution..f95 (code 1).

the file 't.f95' is a simple 'hello' test program can be compiled by gfortran.

(Just the same problems still exist...)

Then I try a  command 'which daalvars.csh',the result is :

/usr/bin/which: no daalvars.csh in (/opt/intel/compilers_and_libraries_2016.0.109/linux/bin/intel64:/opt/intel/compilers_and_libraries_2016.0.109/linux/mpi/intel64/bin:/opt/intel/debugger_2016/gdb/intel64_mic/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/home/kemeng-li/bin).

Perhaps I should add another source or sth?

Now I have added 'source /opt/intel/compilers_and_libraries_2016.0.109/linux/bin/ifortvars.sh intel64'  in the file '.bashrc'.

PS.

'which ifort' outputs :

/opt/intel/compilers_and_libraries_2016.0.109/linux/bin/intel64/ifort

'ifort --v' outputs :

ifort (IFORT) 16.0.0 20150815
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

Now my fedora version is :

4.1.6-200.fc22.x86_64

Thank you!

[Kevin_D_Intel]

I'm a bit confused but I guess you are saying the compiler is now working for you, is that right?

I gather when you first tried compiling you had not sourced the compilervars.sh script?  That sure is a strange and confusing error...

[Lee_A_]

Kevin Davis (Intel) wrote:

I'm a bit confused but I guess you are saying the compiler is now working for you, is that right?

I gather when you first tried compiling you had not sourced the compilervars.sh script?  That sure is a strange and confusing error...

I think it works

Really a confused error,I add 'source /opt/intel/compilers_and_libraries_2016.0.109/linux/bin/compilervars.sh intel64' an I have the same error....Can I know sth about the file 'daalvars.csh*' ,for it always tells me ：

‘‘fortcom: Severe: No such file or directory

... file is 'daalvars.csh*'
compilation aborted for t.f95 (code 1)‘’

I want to get some information about the file 'daalvars.csh' ,it's function or path or sth else.I guess it is a lack of compilation file....

Thank you !

[TimP]

Normally, in order to bring the installed Fortran components on path, you would source compilervars.csh by specifying a full path to where you installed it (assuming you are running csh or tcsh).  I suppose that should automatically source the daalvars script if that is also installed.. daalvars would be needed only if you are calling daal libraries.  I haven't seen specific documentation on use of daal with Fortran.

If you move libraries after installing, or interrupt installation, you are likely to get such errors, as the scripts should be set up according to the choices of library options at install time.  The entire set of libraries are expected to be installed in the same file system tree (either default or what you specify when you take the option to modify configuration).   I suppose attempting to use online installation is  likely to produce such problems, if you don't have a local repository to avoid requiring repeated internet connection.

[Lee_A_]

Tim Prince wrote:

Normally, in order to bring the installed Fortran components on path, you would source compilervars.csh by specifying a full path to where you installed it (assuming you are running csh or tcsh).  I suppose that should automatically source the daalvars script if that is also installed.. daalvars would be needed only if you are calling daal libraries.  I haven't seen specific documentation on use of daal with Fortran.

If you move libraries after installing, or interrupt installation, you are likely to get such errors, as the scripts should be set up according to the choices of library options at install time.  The entire set of libraries are expected to be installed in the same file system tree (either default or what you specify when you take the option to modify configuration).   I suppose attempting to use online installation is  likely to produce such problems, if you don't have a local repository to avoid requiring repeated internet connection.

After the command 'source compilervars.csh' , there is :

'bash: compilervars.csh: line 32: syntax error near unexpected token `$argv[1]'
bash: compilervars.csh: line 32: `switch ( $argv[1] )'

Before it Ihave source 'compilervars.sh' and 'ifortvars.sh'.

PS. If source 'fortvars.csh',I have the same problem in 'compilervars.csh'

[Lorri_M_Intel]

You're using the 'bash' shell?  Continue using the .sh versions, not the .csh versions of the startup scripts, sorry for the confusion above.

all that said - you should be using the ipsxevars script, not the compilervars script.  That should set things up correctly to find the daalvars script.

But, I've got to say that *this* is really weird:

‘‘fortcom: Severe: No such file or directory

... file is 'daalvars.csh*'
compilation aborted for t.f95 (code 1)‘’

fortcom should be an executable which is the actual Fortran compiler, and this executable should never be looking for daalvars.csh.

Can you issue "which fortcom" please, in case there is a script somewhere on your path that is being invoked instead of the compiler executable?

           --Lorri

[Lee_A_]

Lorri Menard (Intel) wrote:

You're using the 'bash' shell?  Continue using the .sh versions, not the .csh versions of the startup scripts, sorry for the confusion above.

all that said - you should be using the ipsxevars script, not the compilervars script.  That should set things up correctly to find the daalvars script.

But, I've got to say that *this* is really weird:

‘‘fortcom: Severe: No such file or directory

... file is 'daalvars.csh*'
compilation aborted for t.f95 (code 1)‘’

fortcom should be an executable which is the actual Fortran compiler, and this executable should never be looking for daalvars.csh.

Can you issue "which fortcom" please, in case there is a script somewhere on your path that is being invoked instead of the compiler executable?

           --Lorri

    The ''ipsxevars.sh'' does not exist?I can not find it.

     The result of 'which fortcom' is :

/opt/intel/compilers_and_libraries_2016.0.109/linux/bin/intel64/fortcom

     I‘m sorry for the trouble. Thank you for your help!

[Kevin_D_Intel]

Missing ipsxevars.sh just means you installed the Composer Edition and not the Professional or Cluster edition so that is not a problem. It appears you have source’d the appropriate compilervars.sh and have your environment setup but the message you received when compiling is very perplexing.

Can you please show us the content of the t.f95 file?   (Either attach a copy of the file to your reply or cut-and-paste the contents into your reply.)

Something else to do is compile using your earlier command-line but add the -watch and capture the stderr/stdout to a file and attach that file to your reply. So use this command:

ifort -free -Tf t.f95 -watch &> output.txt

And then attach the output.txt file to your reply.

[Lee_A_]

Kevin Davis (Intel) wrote:

Missing ipsxevars.sh just means you installed the Composer Edition and not the Professional or Cluster edition so that is not a problem. It appears you have source’d the appropriate compilervars.sh and have your environment setup but the message you received when compiling is very perplexing.

Can you please show us the content of the t.f95 file?   (Either attach a copy of the file to your reply or cut-and-paste the contents into your reply.)

Something else to do is compile using your earlier command-line but add the -watch and capture the stderr/stdout to a file and attach that file to your reply. So use this command:

ifort -free -Tf t.f95 -watch &> output.txt

And then attach the output.txt file to your reply.

The 't.f95' is a simple 'hello program' for testing and can be compiled with gfortran.

The content is:

!------------------------------------------------------------------------------

Program t
  Write(*,*) 'hello'
End Program t

!--------------------------------------------------------------------------------
After 'ifort -free -Tf t.f95 -watch &> output.txt',there is the file ‘output.txt‘：

477635

Thank you！

[mecej4]

Some files appear to have become corrupted with ANSI/DEC terminal control escape sequences. I see the following in the file attached to #13:

    -I/opt/intel/compilers_and_libraries_2016.0.109/linux/daal
daalvars.csh*
daalvars.sh*

Whether those escape sequences are in some script or in the compiler driver itself, I do not know, but this should be easy for Intel people to track down.

[Lee_A_]

Kevin Davis (Intel) wrote:

Missing ipsxevars.sh just means you installed the Composer Edition and not the Professional or Cluster edition so that is not a problem. It appears you have source’d the appropriate compilervars.sh and have your environment setup but the message you received when compiling is very perplexing.

Can you please show us the content of the t.f95 file?   (Either attach a copy of the file to your reply or cut-and-paste the contents into your reply.)

Something else to do is compile using your earlier command-line but add the -watch and capture the stderr/stdout to a file and attach that file to your reply. So use this command:

ifort -free -Tf t.f95 -watch &> output.txt

And then attach the output.txt file to your reply.

PS.After 'ifort -free -Tf t.f95'  I got  a folder 'intel' contains files of 'xx.db',I attach the folder 'intel' here:

477644

[Lee_A_]

mecej4 wrote:

Some files appear to have become corrupted with ANSI/DEC terminal control escape sequences. I see the following in the file attached to #13:

    -I[3;J[H[2J/opt/intel/compilers_and_libraries_2016.0.109/linux/daal
[0m[38;5;40mdaalvars.csh[0m*
[38;5;40mdaalvars.sh[0m*

Whether those escape sequences are in some script or in the compiler driver itself, I do not know, but this should be easy for Intel people to track down.

I am not very good at computer.....I use ifort for the requirement of CosmoMC(of course ifort is faster than gfortran).

I cannot find the the solution method on general webs,perhaps I meet a strange fault.....

[mecej4]

No, at this point we have to wait for Intel to investigate the problem. 

[Kevin_D_Intel]

Thank you for the output of -watch. That certainly helps understand what is contributing to the weird errors when compiling but it is still a mystery exactly what has led to the corruption mecej4 notes.

One more request before you proceed with a recommendation for reinstalling the product. Can you execute the command shown below and attach the envout.txt file to this forum thread.

env &> envout.txt

Back when you said you upgraded to Fedora 22 (post #5), I’m guessing that *did not* include reinstalling Parallel Studio XE 2016 and at this point to resolve this issue I recommend uninstalling the Parallel Studio XE 2016 and then reinstalling it.

When reinstalling, we could have you complete the full installation again to see whether the problem resurfaces or (my recommendation) use the installation menus to exclude the Intel(R) Data Analytics Acceleration Library 2016 (DAAL) component that I do not anticipate is relevant to your interests. Again, I recommend the latter option to exclude DAAL and here’s what you need to do during the installation:

Start the installation and  upon reaching what should be Step 5 of 7 | Options. Select the option to Change the components to install (option 3). Under this sub-menu, use the option for Intel(R) Data Analytics Acceleration Library 2016 (I believe that is choice 13).  Under this DAAL sub-menu, select option 2 which should remove the “x” for this DAAL component meaning it will not be installed. Next press Enter to return to the previous Component Selection menu where you press Enter again to return to the previous menu where you should see the Start installation Now option which you can now use to complete the installation.

After reinstalling, try the earlier advice about using ifort as:   ifort -free -Tf t.f95

Keep us posted and thank you for your patience in working through this issue.

[Kevin_D_Intel]

Here is something else to check perhaps before you reinstall. Run the command below and show us the output.

echo $DAALROOT

And if that is set, the run the command unset DAALROOT and then retry the ifort compilation I noted in my previous reply to see if that works.

[Lee_A_]

Kevin Davis (Intel) wrote:

Here is something else to check perhaps before you reinstall. Run the command below and show us the output.

echo $DAALROOT

And if that is set, the run the command unset DAALROOT and then retry the ifort compilation I noted in my previous reply to see if that works.

Here is the file 'envout.txt' after 'env &> envout.txt ' :

477681

After ''echo $DAALROOT'' ,it outputs :

opt/intel/compilers_and_libraries_2016.0.109/linux/daal daalvars.csh* daalvars.sh* /opt/intel/compilers_and_libraries_2016.0.109/linux/daal/bin

Then 'unset DAALROOT ' ,use '' ifort -free -Tf t.f95'' , the error still exists.....I'll reinstall the software later following your recommendation and I'll feedback the result.

Thank you for your patience!

[Kevin_D_Intel]

Thank you for all the details. Those are helping understand where the original compiler error has come from. From what I see, the whole set of important environment variables (LD_LIBRARY_PATH, PATH, etc.) are corrupted with a malformed DAAL related path. For reasons I don’t yet know, it appears the underlying daalvars.sh (called automatically by source’ing compilervars.sh) malfunctioned on your system leading to a malformed daal path that was then incorporated into these important environment variables.

Here is what I’d like you to do as a work around. Copy the file /opt/intel/compilers_and_libraries_2016.0.109/linux/bin/compilervars.sh to your home directory. Open this copy in your home area with your preferred editor. Next, for lines 106-108 as shown below, delete them from your file.

106     if [ -e $PROD_DIR/daal/bin/daalvars.sh ]; then
107          . $PROD_DIR/daal/bin/daalvars.sh $TARGET_ARCH
108     fi

Next, save these changes and exit the editor. Next, from a fresh login window on your system, from your home directory run the command: source ./compilervars.sh intel64

Next, try the compilation as we have asked before using your t.95 source file (e.g. ifort -free -Tf t.f95)

If that works then you will finally be able to move forward.  Then, just for now, when you login and want to use the compiler you can use your local copy of compilervars.sh. If you have root access and you feel comfortable making a change to the script in the /opt/intel area, then you could edit it and insert a comment character # at the beginning of lines 106-108. That edit could then be undone once we understand the root cause of the malformed daal path.

Once I get you moving forward I'll come back and ask if we can conduct some other tests on your system if needed to understand the daalvars.sh malfunction.

Keep me posted!