statically link library in make for c++/gfortran program

[LMHmedchem]

Hello,

I have a program that uses a fortran library, libgfortran.so.3. One of the other systems I am running this on does not have this library anymore. I think it is now libgfortran.so.5 which is not compatible. There are some other issues building on the newer system.

For now, the program will run fine if I just put a copy of libgfortran.so.3 in the right place on the system that doesn't have it. It seems that a better option would be to static link the library so that the library code is built into the program.

I am not sure how to do this. The program is a c++ program with a call to a Fortran function, at least the entry point to the program is in the c++ code. The c++ src files and fortran src files are compiled separately and then linked up. As long as you keep the syntax correct in the call to the fortran subroutine this works well. The build rule for the program is,

$(BDIR)/testProcess: $(OBJSC)
    $(FCOMP) $(OPTIMIZE) -o $@ $(INCLUDES) $(OBJSC) -lstdc++ -lpthread

# $(OBJSC) is a list of both the c++ and fortran objects
# $(FCOMP) = gfortran
# $(OPTIMIZE) = -O2
# $(INCLUDES) = -I${SOURCELOC}/src_common_depend

Since the recipe line starts with gfortran, this looks like it is built as a fortran program with the C++ library linked. I'm really not sure about that. This system has both libgfortran.so.3 and libgfortran.so.1 installed.

How can I modify the make build rule to statically link libgfortran.so.3, or am I not at all understanding how this all works?

LMHmedchem

[salem_c]

From the man page

-static-libgfortran
On systems that provide libgfortran as a shared and a static library, this option forces the use of the static version. If no shared version of libgfortran was built when the
compiler was configured, this option has no effect.

So perhaps your final make rule is

$(FCOMP) -static-libgfortran $(OPTIMIZE) -o $@ $(INCLUDES) $(OBJSC) -lstdc++ -lpthread

[LMHmedchem]

So perhaps your final make rule is

$(FCOMP) -static-libgfortran $(OPTIMIZE) -o $@ $(INCLUDES) $(OBJSC) -lstdc++ -lpthread

Thanks allot, I will try that.

For additional information, there are a couple of versions of libgfortran on this system. How does the linker know which one to use since the above recipe doesn't specify so.3, so.1, etc? I guess one could assume that the linker static includes the same library it would link to dynamically but it would be very nice to understand the methodology by which all of that works.

For example, in some instances I add -lusb or -lusb-1.0. I have no idea which library these instructions refer to. How does the linker know what -lusb-1.0 is supposed to link to?

I can find,

/usr/lib64/libusb-1.0.so        // symlink to libusb-1.0.so.0.1.0
/usr/lib64/libusb-1.0.so.0      // symlink to libusb-1.0.so.0.1.0 
/usr/lib64/libusb-1.0.so.0.1.0

so the above entries all link to libusb-1.0.so.0.1.0 but how does make know that to interpret -lusb-1.0 like that?. Surely there must be a file or database or something that make uses to resolve this. It would be very helpful to understand how this works.

LMHmedchem

[salem_c]

The linker doesn't know about symlinks.

Given -lusb-1.0, the linker resolves it to libusb-1.0.so and then asks the file system "give me file libusb-1.0.so"

It's the file system which then looks to see, "ooh, symlink...." and follows the chain until it finds an actual file.

The same will be true of any other library you might have.