Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
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


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");


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


This seems to be to function call that forces the dependencies:

$ objdump -x hello | grep "GLIBC_2.11"
    0x06969191 0x00 11 GLIBC_2.11
0000000000000000       F *UND*  0000000000000000              __longjmp_chk@@GLIBC_2.11

It seems that Fortran runtime library for ifort (FRTL) was compiled with "-D_FORTIFY_SOURCE=1" and in one of the FRTL calls "longjmp" function was called.

You can reproduce the same dependency in C like this:

#include <stdio.h>
#include <setjmp.h>

int main() 
    jmp_buf jb ;
    int result = setjmp(jb) ;
    if (!result)
        printf("Before jump\n") ;
        longjmp(jb, 42) ;
        printf("After jump, result = %d\n", result) ;

If you compile it with "-D_FORTIFY_SOURCE=1", then the same dependency appears:

$ objdump -x hello-c | grep "GLIBC_2.11"    
    0x06969191 0x00 05 GLIBC_2.11
0000000000000000       F *UND*  0000000000000000              __longjmp_chk@@GLIBC_2.11
Bottom line, for a given compiler FRTL is created in a certain way and cannot be changed.
Why do you need to eliminate the dependency on GLIBC 2.11?