Makefile errors using gfortran -static option

1

Hello, I’m on RHEL 7 64 bit.

One of my have-to-have Makefiles is giving me the following error messages:

/bin/ld: cannot fine -lgfortran
/bin/ld: cannot fine -lm
/bin/ld: cannot fine -lquadmath
/bin/ld: cannot fine -lm
/bin/ld: cannot fine -lpthread
/bin/ld: cannot fine -lc

It’s probably because of the -static gfortran option.

The Makefile is:

OPTIONS		= -g -Wall -Werror -fmax-errors=1 -fcheck=all -fPIC -std=legacy -static

SRC		= King.f Queen.f Bishops.f

.SUFFIXES : .o .f
.f.o:
	gfortran $(OPTIONS) -c $*.f

OBJS		= $(SRC:.f=.o)

MOVEDIR		= ../../moves/CurrentMoves

LIBS		= $(MOVEDIR)/*.a -pthread

EXECUTABLE	= PlayTheGame

PROGRAM:	$(OBJS) 
		gfortran $(OPTIONS) $(OBJS) $(LIBS) -o $(EXECUTABLE)

What do I do about this? How do I get it to compile? Again, the -static option has to be used!

Thank you

P.S.: I tried to install using the following without success:

yum install install libgfortran5.x86_64
yum install install compat-libgfortran-41.x86_64 
yum install libgfortran4.x86_64
yum install compat-libgfortran-41.x86_64
4

Is there advantage of using -static ?

6

The respective static libraries / archives have to be available to link statically, ld is complaining because it cannot find libgfortran.a, libquadmath.a, libm.a, libpthread.a and libc.a for linking, most likely because they are not installed.

Best check your distribution and package manager for the packages with the archives. Note that not all distributions actually ship static libraries, meaning static linking is not always possible.

7

Not quite. Static linking means that the procedures etc. needed by your program are extracted from the (static) library and incorporated into the executable program being linked. It does not need those libraries anymore.

2 Likes
8

I think “-static” is not being clearly described in this thread ( and I probably can’t do better myself )
Is -static an abbreviation for -static-libgfortran ?

“-static” in this context refers to linking, when the libraries are either “statically” included in the resulting .exe when it is being generated or are dynamically linked with .exe and included when it is “run”.

If the .exe is statically linked, then there is no requirement to have the compiler libraries available (in the path) when you run the program, as the necesary libraries have been included in the .exe.

If the .exe is dynamically linked, then the .dll libraries must also be available when you run the program, as well as when the .exe is built.

Which option you choose depends on what compiler libraries are available when you link the program. It depends on what is installed with the compiler.
For example, I use two gfortran compilers on windows.
equation.com version only provides static libraries and so “-save” is implied.
mingw-w64 version provides dynamic link libraries by default and so the path for the library files must be available when the program is run.
I must admit, I only use the default option with each compiler.

The advantage of dynamic .dll is that the library can be updated without the need of remaking the .exe, although I have rarely utilised this option.
The advantage of -save static build is that the .exe is more easily portable. It can be transferred to other PC without the need to check the libraries are installed and in the path.

In practice, I prefer equation.com’s -save implementation, as you don’t have to keep track of which library version are in the path when you run the program, which can be a problem if you are changing compiler versions. Moving .exe files between pc’s is not as significant an issue, as I usually use -march=native, which also limits .exe portability.
I personally do not see many practical benefits of using dynamic .dll builds, but I am sure there are cases where they are required, especially where third-party static libraries are not available.

The solution to your problem may be to remove -save and use default, unless third-party libraries are required.

1 Like
9

I don’t think that it is a Gfortran option at all. Can you provide a link to the Gfortran documentation describing -static? When a compiler driver encounters a user-provided option that it does not recognize, it may pass such an option to the linker without attempting to interpret it. The result can be a failure to link because the linker is attempting to obey an option that you meant for the compiler.

You stated that your makefile is “have-to-have”. I have no idea what that means, and I suspect that you may be mistaken about why you require it.

12

There is actually no mention of -static in the linked pages, the GFortran manual page mentions -static-libgfortran for statically linking libgfortran if the static library is available.

You are looking for -static which is an option gfortran will pass-through to the linker ld

-static

Do not link against shared libraries. This is only meaningful on platforms for which shared libraries are supported. The different variants of this option are for compatibility with various systems. You may use this option multiple times on the command line: it affects library searching for -l options which follow it. This option also implies –unresolved-symbols=report-all . This option can be used with -shared . Doing so means that a shared library is being created but that all of the library’s external references must be resolved by pulling in entries from static libraries.

Again this doesn’t work if there are only shared libraries and no static libraries installed, which is why you are getting an error from the linker.

2 Likes
13

The first link points to the man page for the Sun f77 compiler. It has nothing to do with Gfortran, and it does not provide a -static option. Gfortran does not have a -static option either.

15

Best check the documentation of your system package manager.

17

Actually no, RHEL is one of the distributions not shipping static libraries.