Undefined symbols link problem

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:

module test_mod
integer, save :: k2_4_row
end module

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

5 сообщений / 0 новое
Последнее сообщение
Пожалуйста, обратитесь к странице Уведомление об оптимизации для более подробной информации относительно производительности и оптимизации в программных продуктах компании Intel.
Аватар пользователя 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...

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. 

Зарегистрируйтесь, чтобы оставить комментарий.