Error: ld: cannot find -lm


Problem : compiling with -fast or -static causes a linker error "ld: cannot find -lm"


Environment : Redhat Enterprise Linux 6, Fedora Core 11, 12, 13, 14 other linux distros possible


Root Cause :  RHEL 6, FC12, 13, 14 do not ship with static versions of glibc OR the libraries are in a directory that is not normally pathed.  Thus, there is no static version of libm to link by default.  (the linux community is trying to discourage static linking and move the community to a dynamic linking model.  Thus, recent linux distros are not shipping/installing glibc-static by default OR are putting the static libs in paths that are not searched by default.)


Resolution :

If you want to link statically, that is with -static or -fast (which contains -static), you will need the static versions of glibc.  Keep in mind that static linking is being discouraged by the larger linux community.  You may, of course, use -static-intel to statically link the Intel libraries.  However, if you want to also statically link the system libraries in glibc you will need the static versions of glibc.

CASE 1, PATHS: 64bit compiler and x86_64 64bit OS:   RHEL 6.x distros may put the libs in path not normally searched, /usr/lib/x86_64-redhat-linux5E/lib64/   Add this path explicitly:

Possible workarounds are:
1) Specify library location using -L option
ifort -static hello.f90 -L/usr/lib/x86_64-redhat-linux5E/lib64/
2) Add the location of libraries to LIBRARY_PATH variable

SECOND CASE: 32 bit OS/gcc/Intel Compiler and/or static libs are not found in /usr/lib/x86_64-redhat-linux5E

Install the static version of glibc.  Research your distribution for the appropriate package to install.  For example, for RHEL 6 and FC12 and FC13:

Try
yum install glibc-static

OR
x86_64:
yum install glibc-static.x86_64

IA32:
yum install glibc-static.i686

(you may have to research and find a 32bit version of glibc-static.  Use rpmfind or some other web search to find an appropriate 32bit version of glibc-static that matches the 64bit version you installed above with yum).

Another work-around: avoid static linking - don't use the -static or -fast compiler options.


For more complete information about compiler optimizations, see our Optimization Notice.

Comments

I think static linking has

I think static linking has some other benefits:
- linker can omit unused functions from the library
- compiler can perform cross-object optimization
- library must be compiled with -fPIC (position independend code), which is slower due to different adressing mode.

As for the size advantage of shared libraries due to reuse among programs, it is also doubtful for third party programs.
It works well for programs shipped with the Linux, where everything is recompiled by maintainers of the distribution. But it is a nightmare for developers of third party applications which need to deliver a runtime which will run on any Linux distribution. So any half decent application must ship its own copy of shared libraries.
For example, firefox ships its own shared libssl3.so, libnspr4.so, libsoftokn3.so, libnss3.so,... duplicating the ones present on the system.
I think abandoning static libraries is a typical Linux case of forcing an approach, which works well for distribution maintainers, but not so well for programmers. Like: we want to solve our problems, but we don't care about your problems.


Some believe there is a performance benefit, but it is minimal. Loading a shared lib does have overhead BUT it's 1 time at start and would only be seen by short running applications. For anything that runs for a minute or more it's doubtful you'll see any benefit in performance from static libs.

the benefit of static linking is that the executable has no dependencies on shared libs - this helps when you move apps to systems that may or may not have the libs OR the right version of the libs.

ron