Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!

ifort GLIBC dependencies

Nikolaos_S_
Beginner
80 Views

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.

 

0 Kudos
1 Reply
van_schoot__hans
Beginner
80 Views

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).

Reply