Undefined symbols link problem

[cu_lepp]

I am using ifort V13: mac:~/bmad/bmad_dist/test> ifort --version ifort (IFORT) 13.0.1 20121010 Copyright (C) 1985-2012 Intel Corporation. All rights reserved. Running on OSX 10.7.4: mac:~/bmad/bmad_dist/test> uname -a Darwin rrsdhcp-10-32-35-37.redrover.cornell.edu 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr 9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64 The test code to see the problem: test_mod.f90: -------------------- module test_mod integer, save :: k2_4_row end module test.f90: ------------- program test use test_mod implicit none k2_4_row = 7 end program If I compile and link everything on one line all is fine: mac:~/bmad/bmad_dist/test> ifort test_mod.f90 test.f90 If I put the test_mod.f90 file in a library I get an Undefined symbol error: mac:~/bmad/bmad_dist/test> ifort -c test_mod.f90 mac:~/bmad/bmad_dist/test> ar -r libtest.a test_mod.o mac:~/bmad/bmad_dist/test> ifort test.f90 libtest.a Undefined symbols for architecture x86_64: "_test_mod_mp_k2_4_row_", referenced from: _MAIN__ in ifortbZRW8Y.o ld: symbol(s) not found for architecture x86_64 Can someone tell me what is going on here? The file test_mod.o is of the correct type: mac:~/bmad/bmad_dist/test> file test_mod.o test_mod.o: Mach-O 64-bit object x86_64

[Ferdinand_T_]

Since nobody replied yet, maybe my uninformed answer is better than nothing:

For OS X, ifort has an option "ifort -staticlib" which can be used instead of the ar tool (1)
(which I only know about because I just learned about static linking on linux, so I am anything but an expert...)

Maybe this approach avoids some of the difficulties creating staic libraries with the mac OS X version of ar (2)

1) http://software.intel.com/sites/products/documentation/hpc/composerxe/en-us/2011Update/fortran/win/bldaps_for/common/bldaps_create_stlib.htm

2) http://lists.apple.com/archives/fortran-dev/2006/May/msg00027.html

[cu_lepp]

Using "ifort -staticlib" does fix things. Also using "ranlib -c". Another thing that fixes it is initializing the variable so changing test_mod.f90 to this works:

module test_mod
integer, save :: k2_4_row = 0
end module

So this definitely looks like a compiler bug but there are some simple fixes.

Much thanks for your help.

[Ferdinand_T_]

cu_lepp wrote:

So this definitely looks like a compiler bug but there are some simple fixes.

I dont think you should blame the compiler here. The culprit is definitely your (apples) archiver, which does not include common symbols from your object files (e.g. uninitialized global variables in the modules) into the libraries table of content

Hence, in your original library, the linker cannot find the global "k2_4_row" any more. This is just apples idea about static libraries.

However, with ranlib and the -c option you can manually add all "common" symbols to the libraries TOC. Or, of course, initialize your global variable, so it appears in your object file as a symbol of type "initialized data", which now "ar" lists in the libraries TOC. Both approaches finally make "k2_4_row" accessible to the linker.

[cu_lepp]

I am not a compiler guru so let me ask this question: Why is ifort, when it makes the .o file, marking the symbol as common? When I use gfortran it marks the symbol as "S" (when using the "nm" command) and there are no problems. When an initial value is given, ifort marks the symbol as "B" (bss section symbol). Seems to me that the symbol should not be marked differently if it is initialized and if it is not. Fortran is not C/C++ and you cannot declare a global variable in multiple places. 

Note: I do think you are correct that ar should be putting common symbols in the symbol table so I'm not blameing ifort entirely.