gfrtran capable of static and dynamic linking

brownwrap · 10-08-2013, 01:45 PM

OK, let me start of by saying I am not a programmer. I am a system administrator that has been asked to install software. I have been asked to install a version of gfortran that can be used to link using both static or dynamic methods. My question is why wouldn't gfortran be able to do this out of the box? Aparently the gfortran that is currently installed can't, thus the reason my user is requesting a reinstallation. Here is the output of gfortran -v

Code:

[ramos@kahuna ~]$ gfortran -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) 
[ramos@kahuna ~]$

NevemTeve · 10-08-2013, 02:04 PM

> Aparently the gfortran that is currently installed can't

What tests proved this statement?

PS: by 'dynamic method' you mean 'using/creating shared libs'?

turtleli · 10-08-2013, 04:56 PM

Have you checked whether static glibc libraries are installed? I believe Red Hat based distros do not install them by default (I could be wrong here).

On a HPC (Scientific Linux) I have access to I cannot compile static fortran programs because it's missing some static libraries (specifically libm.a). On my Slackware desktop the relevant static libraries are present and I can build static programs with that. I do not think it is related to the compiler.

suicidaleggroll · 10-08-2013, 05:12 PM

Probably just missing the static libs. As turtleli said, they're separate from the dynamic libs and often aren't installed by default. On RHEL/CentOS, the dynamic libs are part of the package "glibc", while the static libs are in "glibc-static". Remember that there are 32-bit and 64-bit versions of each:

glibc.x86_64
glibc.i686
glibc-static.x86_64
glibc-static.i686

RPM-based distros are a champ with multilib setups, so feel free to install all four if you want.

brownwrap · 10-09-2013, 01:01 PM

Thank you all for the insightful information. I am not quite there yet though. What is really curious is, the user who requested the new compiler gave me a test program. On the SAME machine, it runs for me, but not for him. We are in fact using Red Hat, and all of our machine use RH Satelite to configure machines, though this one may be slightly different. I followed the suggestions and installed glibc.static, still get the same result on a test box I have set up.

Code:

compile options: '-I/tmp/tmphWYLPN/src.linux-x86_64-2.7 -I/opt/ActivePython-2.7/lib/python2.7/site-packages/numpy/core/include -I/opt/ActivePython-2.7/include/python2.7 -c'
gfortran:f90: test_f2py.f90
/usr/bin/gfortran -Wall -Wall -shared -static-libgfortran /tmp/tmphWYLPN/tmp/tmphWYLPN/src.linux-x86_64-2.7/test_f2pymodule.o /tmp/tmphWYLPN/tmp/tmphWYLPN/src.linux-x86_64-2.7/fortranobject.o /tmp/tmphWYLPN/test_f2py.o -lgfortran -o ./test_f2py.so
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/4.4.7/libgfortran.a(transfer.o): relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/libgfortran.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/4.4.7/libgfortran.a(transfer.o): relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/libgfortran.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
error: Command "/usr/bin/gfortran -Wall -Wall -shared -static-libgfortran /tmp/tmphWYLPN/tmp/tmphWYLPN/src.linux-x86_64-2.7/test_f2pymodule.o /tmp/tmphWYLPN/tmp/tmphWYLPN/src.linux-x86_64-2.7/fortranobject.o /tmp/tmphWYLPN/test_f2py.o -lgfortran -o ./test_f2py.so" failed with exit status 1
make: *** [test_f2py.so] Error 1

turtleli · 10-09-2013, 03:36 PM

Ok. From your latest information I don't think it has anything to do with static glibc. I thought your user was creating static programs (and using the -static option) but it seems your user is trying to make static and dynamic libraries instead.

If this is indeed the case then your user might be building the libraries wrong. The compile options strike me as peculiar since "-shared" and "-static-libgfortran" aren't normally used together. The options also do not work together when attempting to build a shared library in Scientific Linux, which will apply to Red Hat as well.

Perhaps you should direct your user to this fortranwiki faq, which shows the correct way to create shared and static libraries.

sundialsvcs · 10-09-2013, 06:42 PM

I cannot speak directly to the case of "the GNU Fortran compiler," but I think that I can say that the decision of "static vs. dynamic linking" is going to be "a compiler option."

When your program's source-code has been successfully processed, the compiler now has a choice: should it resolve all of the external-library dependencies now ("early binding"), or should it instead generate a program that will attempt to resolve those dependencies at runtime ("late binding")? The choice is yours. (And the real answer ... see below ... is "both.")

In the case of early binding, the requisite libraries will need to be available to the linker (as *.o files immediately. The necessary subroutines (object code ...) will be retrieved from the libraries and bound into the executable program. If they are not available right now, the step will not succeed.

In the case of late binding, the program will be built in such a way that it will only successfully execute if the necessary libraries *.so can be located (by the so-called "dynaloader").

Obviously, all programs employ more-or-less of a mixture of these two techniques. Even an early-bound program will still be generated with numerous late-binding dependencies on (at least ...) glibc.

NevemTeve · 10-09-2013, 11:45 PM

What do you really want? (Or what does your user really want?) Is this a random play with linker-options (-shared, -static-libgfortran, -lgfortran), or does he actually want to get something? A shared object that integrates libgfortran.a? That is not possible, because objects in libgfortran.a aren't usable that way (cf -fPIC compiler-option).