Static libraries are replaced by dynamic counterparts at link time

Static libraries are replaced by dynamic counterparts at link time

The program I am building contains FORTRAN code, and the program is being built on a Linux O/S. Two libraries I need to support the FORTRAN code are libifcore and libifport. The compiler suite has these libraries located in the directory parallel_studio_xe_2011_spl_update3_intel64/composer_xe_2011_sp1.11.339/compiler/lib/intel64. Since these libraries are not located in a standard library area, in order to link I must use the -L option to enter the specific path to directory containing the required libraries. I originally attempted to link in the static libraries, libifcore.a and libifport.a, using  options -static-intel -L{library path}. Despite this the compiler suite links in dynamic libraries and instead.

The problem begins here. I need the libifcore and libifport libraries to link in statically. The program goes to a client on a separate computer system with the same Linux O/S but does not have the parallel_studio_xe_2011_spl_update_intel64 compiler suite available. So when the client runs the executables they receive the error message: "error while loading shared or cannot open shared object file: no such file or directory.

I was able to work around the problem by statically linking libifcore_pic.a into my program instead. But I am concerned because the future FORTRAN projects I have may require support from other static libraries with dynamic library counterparts from the same directory area. This poses two questions:

First Question: Even though the libraries libifport and libifcore can be found with static .a extensions in the parallel_studio_xe_2011_spl_update3_intel64  lib/intel64 directory, why can these libraries only be linked with their dynamic counterparts and 

Second Question: If the intention is to have the libifport and libifcore be available as dynamic libraries only, why are these libraries located in a nonstandard library directory location which forces the use of the –L option in-order to link in these libraries?

3 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.


If it is your intention to link against the static versions of the libraries, dont use the -L and -l options, just specify the full path to the .a file with no flags before it.  A .a file on linux just just a library of .o object files and you use them in the same way when linking your application.  

To answer your second question, you are meant to redistribute those shared libraries with your application.  In the composer_xe directory look for Documentation/en_US/fredist.txt, which lists the files considered redistributable.

In a normal installation of ifort, the static and dynamic libraries, where both are available, are in the same directory e.g.


and the -static-intel option works for me.  It's certainly possible to move the .a libraries somewhere else, but I don't believe there's an install option which does that.    MKL does expect you to supply the full path of each static library (not using -L) when you choose a static MKL link.

A few of the libraries, notably libiomp5, are no longer supplied in .a format, so you would need to supply them with your binary, or refer to the redistributable.  There's a growing trend toward linux providing only dynamic libraries, so as to enforce, for example, the incompatibility of a build running against an older libc than it was built against.

Leave a Comment

Please sign in to add a comment. Not a member? Join today