ifort GLIBC dependencies

[Nikolaos_S_]

When compiling with ifort 17 on Linux, I notice very different GLIBC dependencies than when compiling with icc.  In particular, the following code

      program main
      write(*,*) 'Hello world!'
      end program main

when compiled on my RHEL 6 system (GLIBC2.11) produces an executable that when examined with objdump -x shows dependencies on 

    0x0d696914 0x00 10 GLIBC_2.4
    0x0d696913 0x00 08 GLIBC_2.3
    0x0d696917 0x00 07 GLIBC_2.7
    0x06969191 0x00 06 GLIBC_2.11
    0x09691974 0x00 05 GLIBC_2.3.4
    0x09691a75 0x00 02 GLIBC_2.2.5

On the other hand, an equivalent C program:

#include <stdio.h>

int main() {
  // call a function in another file
  printf("Hello world!\n");

  return(0);
}

shows dependencies only on

    0x0d696914 0x00 04 GLIBC_2.4
    0x09691a75 0x00 03 GLIBC_2.2.5
    0x09691974 0x00 02 GLIBC_2.3.4

Is there a way to eliminate the GLIBC2.11 dependency of the executable generated by ifort?  Compiling with ifort -D_XOPEN_SOURCE=500 results in no complains but identical GLIBC dependencies.

[van_schoot__hans]

Bit late to comment here, but I just ran into the same problem.

Ifort 2017 and newer have the __isoc99_sscanf symbol mentioned in their libifcore, and also __longjmp_chk in libirc. The first generates a GLIBC_2.7 dependency, the second ups this to GLIBC_2.11. I believe this means that ifort 2017 and newer can no longer be used to compile code for older systems such as RHEL/CentOS 5.

To be fair, Intel also states in the release notes of ifort 2017 that they only support RHEL 6/7 (this was 5/6/7 in ifort 2016).