ifx and ifort 2024.0 unusable

[JFH]

Using an Ubuntu system I deleted my old /opt/intel files and thought I had done what the installation instructions for Fortran 2024.0 asked for. But I got

john@johns-laptop:~$ /opt/intel/oneapi/compiler/2024.0/bin/ifx hello.f

ld: cannot find -lgcc: No such file or directory
ld: cannot find -lgcc_s: No such file or directory

Suspecting something was wrong with the installation I tried

john@johns-laptop:~$ sudo apt update
[sudo] password for john:
Get:1 http://security.ubuntu.com/ubuntu jammy-security InRelease [110 kB]
Hit:2 http://ppa.launchpad.net/system76-dev/stable/ubuntu jammy InRelease
Hit:3 http://archive.ubuntu.com/ubuntu jammy InRelease
Get:4 https://apt.repos.intel.com/oneapi all InRelease [4,451 B]
Get:5 http://archive.ubuntu.com/ubuntu jammy-updates InRelease [119 kB]
Hit:6 https://ppa.launchpadcontent.net/ubuntu-toolchain-r/test/ubuntu jammy InRelease
Err:4 https://apt.repos.intel.com/oneapi all InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY BAC6F0C353D04109
Fetched 234 kB in 2s (108 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
434 packages can be upgraded. Run 'apt list --upgradable' to see them.
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://apt.repos.intel.com/oneapi all InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY BAC6F0C353D04109
W: Failed to fetch https://apt.repos.intel.com/oneapi/dists/all/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY BAC6F0C353D04109
W: Some index files failed to download. They have been ignored, or old ones used instead.
john@johns-laptop:~$ sudo apt -y install cmake pkg-config build-essential
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
build-essential is already the newest version (12.9ubuntu3).
pkg-config is already the newest version (0.29.2-1ubuntu3).
cmake is already the newest version (3.22.1-1ubuntu1.22.04.1).
0 upgraded, 0 newly installed, 0 to remove and 434 not upgraded.
john@johns-laptop:~$

What should I do now?

[Ron_Green]

did you source setvars.sh?

source /opt/intel/oneapi/setvars.sh

[JFH]

Yes. I ran this bash script: called ~/bin/ifx

```

#!/bin/bash
# compile Fortran program(s) with option(s) file with ifx
source /opt/intel/oneapi/setvars.sh
compilers="/opt/intel/oneapi/compiler/2024.0" # for ifx, ifort
set -x
$compilers/bin/ifx -standard-semantics -L/lib/gcc/x86_64-linux-gnu/13 -L$compilers/lib -limf -lgcc -lgcc_s "$@"

```

and got these results:

```

john@johns-laptop:~/bin$ ./ifx ../hello.f

:: initializing oneAPI environment ...
ifx: BASH_VERSION = 5.1.16(1)-release
args: Using "$@" for setvars.sh arguments: ../hello.f
:: compiler -- latest
:: oneAPI environment initialized ::

+ /opt/intel/oneapi/compiler/2024.0/bin/ifx -standard-semantics -L/lib/gcc/x86_64-linux-gnu/13 -L/opt/intel/oneapi/compiler/2024.0/lib -limf -lgcc -lgcc_s ../hello.f
john@johns-laptop:~/bin$ ./a.out
./a.out: error while loading shared libraries: libimf.so: cannot open shared object file: No such file or directory
john@johns-laptop:~/bin$ ls -l /opt/intel/oneapi/compiler/2024.0/lib/libimf*
-rwxr-xr-x 1 root root 8448448 Nov 22 18:57 /opt/intel/oneapi/compiler/2024.0/lib/libimf.a
-rwxr-xr-x 1 root root 4591864 Nov 22 18:57 /opt/intel/oneapi/compiler/2024.0/lib/libimf.so
john@johns-laptop:~/bin$

```

I don't understand why ifx could not find /opt/intel/oneapi/compiler/2024.0/lib/libimf.so but ls -l could.

[JFH]

It may help that my corresponding script for ifort worked as I had hoped  it would.

```

john@johns-laptop:~/bin$ cat ./ifort
#!/bin/bash
# compile Fortran program(s) with option(s) file with ifort
source /opt/intel/oneapi/setvars.sh > /dev/null
set -x
/opt/intel/oneapi/compiler/2024.0/bin/ifort -standard-semantics -L/lib/gcc/x86_64-linux-gnu/13 -lgcc -lgcc_s "$@"

john@johns-laptop:~/bin$ ./ifort ../hello.f
+ /opt/intel/oneapi/compiler/2024.0/bin/ifort -standard-semantics -L/lib/gcc/x86_64-linux-gnu/13 -lgcc -lgcc_s ../hello.f
ifort: remark #10448: Intel(R) Fortran Compiler Classic (ifort) is now deprecated and will be discontinued late 2024. Intel recommends that customers transition now to using the LLVM-based Intel(R) Fortran Compiler (ifx) for continued Windows* and Linux* support, new language support, new language features, and optimizations. Use '-diag-disable=10448' to disable this message.
john@johns-laptop:~/bin$ ./a.out
Hello World
john@johns-laptop:~/bin$

```

[Ron_Green]

Ah we were just having this discussion on another Forum outside of Intel.

IFX and IFORT are different in defaults for linux with respect to static vs dynamic linking.  For ifort, -static-intel is on by default.  That is, ifort defaults to link in all Intel libraries statically, except for libicaf (our Coarray fortran library) and libiomp5 (OpenMP),  IFX links MOST of the Intel libraries statically EXCEPT libimf, libintlc in addition to the 2 caf and iomp libs listed above.

to get ifx to link statically, add this option:
-static-intel

That will fix it.

For you example, you source the setvars script in your wrapper script.  Which is correct.  but once you exit that script, all the env settings go away.  Specifically LD_LIBRARY_PATH which setvars.sh sets up to find the dynamic versions of libimf and the other 3 I mentioned.  So from your command line, ifx compiled code without the -static-intel would need you to source setvars.sh again OR set up LD_LIBRARY_PATH to include  /opt/intel/oneapi/compiler/2024.0/lib

Based on the comments on this thread on the other forum, fortran-lang on Discourse, I have 2 bug reports for our Developer Guide to update the info on -static-intel and -dynamic-intel DOCS pages.  Also, I will add this difference between ifx and ifort in our IFORT to IFX Porting Guide. 

[JFH]

Thank you Ron_Green but I still have problems with ifx. I don't know whether the OR in your previous reply was meant to be inclusive or exclusive but I tried both possibilities. For example changing my shell script ~/bin/ifx to include both that LD_LIBRARY_PATH and the -static-intel option produced this result, with libimf.so still not found:

```

john@johns-laptop:~$ cat bin/ifx
#!/bin/bash
# compile Fortran program(s) with option(s) file with ifx
source /opt/intel/oneapi/setvars.sh
compilers="/opt/intel/oneapi/compiler/2024.0" # for ifx, ifort
export LD_LIBRARY_PATH="$compilers/lib"
echo "LD_LIBRARY_PATH is" $LD_LIBRARY_PATH
set -x
$compilers/bin/ifx -standard-semantics -static-intel -L/lib/gcc/x86_64-linux-gnu/13 -L$compilers/lib -limf -lgcc -lgcc_s "$@"
john@johns-laptop:~$ ./bin/ifx hello.f

:: initializing oneAPI environment ...
ifx: BASH_VERSION = 5.1.16(1)-release
args: Using "$@" for setvars.sh arguments: hello.f
:: compiler -- latest
:: oneAPI environment initialized ::

LD_LIBRARY_PATH is /opt/intel/oneapi/compiler/2024.0/lib
+ /opt/intel/oneapi/compiler/2024.0/bin/ifx -standard-semantics -static-intel -L/lib/gcc/x86_64-linux-gnu/13 -L/opt/intel/oneapi/compiler/2024.0/lib -limf -lgcc -lgcc_s hello.f
john@johns-laptop:~$ ./a.out
./a.out: error while loading shared libraries: libimf.so: cannot open shared object file: No such file or directory
john@johns-laptop:~$
 ```

A little more experimentation revealed that to make a program run I had to put ./a.out in at the end of ~/bin/ifx instead of writing it on the command line afterwards. No other compiler I have ever used required that.   Clearly, exporting LD_LIBRARY_PATH was not enough.

[Ron_Green]

You made a common mistake in your compilation line.  You added in libimf explicitly

-L$compilers/lib -limf

you don't need nor want that.  ifx will link in libimf.  And if you use compiler option -static-intel it will bring it in statically and you do not have to call it out at all.

When you explicitly add in libimf, as you did above, it gets added and is added in for dynamic linking.  -static-intel does not look to see if you manually put in imf or any other library.  It only tells the compiler that I want the intel libraries that the driver ifx links implicitly to be statically linked.   your -L$compilers/lib -limf overrides the default and the compiler does not check if it's an Intel library or a user library or any other random library.  It simply adds it to the link line like you asked, and that linking is dynamic.

 so remove -L$compilers/lib -limf 

you don't need nor want to explicitly call it out.

[Ron_Green]

One other question - why don't you just use the "big hammer" and just statically link in EVERYTHING, even your gnu libs?

remove -static-intel

replace with -static

then EVERYTHING gets linked in statically.  Maybe this is easier 

[JFH]

Tried your latest suggestion but changing -static-intel to -static did not work. Evidence:

```

john@johns-laptop:~$ echo 'LD_LIBRARY_PATH is '$LD_LIBRARY_PATH
LD_LIBRARY_PATH is
john@johns-laptop:~$ emacs bin/newifx
john@johns-laptop:~$ echo 'LD_LIBRARY_PATH is '$LD_LIBRARY_PATH
LD_LIBRARY_PATH is
john@johns-laptop:~$ cat ./bin/newifx
#!/bin/bash
# compile and run a Fortran program using ifx
compilers="/opt/intel/oneapi/compiler/2024.0" # for ifx, ifort
source /opt/intel/oneapi/setvars.sh
echo "LD_LIBRARY_PATH is" $LD_LIBRARY_PATH
set -x
$compilers/bin/ifx -standard-semantics -static -limf -lgcc -lgcc_s "$@"
./a.out
john@johns-laptop:~$ ./bin/newifx hello.f

:: initializing oneAPI environment ...
newifx: BASH_VERSION = 5.1.16(1)-release
args: Using "$@" for setvars.sh arguments: hello.f
:: compiler -- latest
:: oneAPI environment initialized ::

LD_LIBRARY_PATH is /opt/intel/oneapi/compiler/2024.0/opt/compiler/lib:/opt/intel/oneapi/compiler/2024.0/lib
+ /opt/intel/oneapi/compiler/2024.0/bin/ifx -standard-semantics -static -limf -lgcc -lgcc_s hello.f
ld: cannot find -lgcc: No such file or directory
ld: cannot find -lgcc_s: No such file or directory
+ ./a.out
./bin/newifx: line 8: ./a.out: No such file or directory
john@johns-laptop:~$

```

Changing -static to -static-intel worked, although I still can't  run ./a.out afterwards unless I either source /opt/intel/oneapi/setvars.sh  at the command line or recompile. Also I'm a bit puzzled by what LD_LIBRARY_PATH became.

Also, I found that replacing source by . made no difference (as the bash manual would suggest). Is there a reason why Intel wants us to use the longer version?

[Ron_Green]

if you add ANY -l<libname> libraries, those will not be statically linked.  So remove:

 -limf -lgcc -lgcc_s 

if you use those -l's, you will dynamically link them. You need only -static, do not call out libraries.

The "./" in front of a script or executable name is a Linux security thing.  By default, Linux frowns upon putting ".", the current directory, into your PATH.  If you have "." in your PATH, then you do not need "./" in front of script names or executable names.  But again, it exposes you to security exploits.  A bad actor can drop trojan horse commands like 'ls', 'cd', etc into your folder and take over your system when you use these common commands.