Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

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?