ABINIT Discussion Forums

I am having issues compiling any of the abinit 6.0.x packages using ifort 11.1.088 on Mac OS X 10.6.4. The problem is that I receive undefined symbol errors while linking abinit, but the symbols appear to exist in the linking command. Here is an overview of what I found:

(1) I created a very minimal configuration using the following command
$ ../configure FC=ifort CC=icc CXX=icpc --disable-all-plugins --with-linalg-libs="-llapack -lblas"
Output attached as configure.log

(2) Run make
$ make
Output here: http://ms.physics.ucdavis.edu/~ldamewood/make.log

(3) One of the undefined symbols from the make log is "_pseudo_pwscf_mp_ecutrho_" from lib45_psp_parser.a. I checked to see if this symbol exists anywhere and it appears to exist in lib45_psp_parser.a itself.
$ nm -A src/45_psp_parser/lib45_psp_parser.a | grep _pseudo_pwscf_mp_ecutrho_
src/45_psp_parser/lib45_psp_parser.a:m_pseudo_pwscf.o: 0000000000000010 C _pseudo_pwscf_mp_ecutrho_
src/45_psp_parser/lib45_psp_parser.a:read_upf_pwscf.o: U _pseudo_pwscf_mp_ecutrho_

(4) This problem does not exist when using gfortran where the symbol type is different.
$ nm -A src/45_psp_parser/lib45_psp_parser.a | grep ecutrho
src/45_psp_parser/lib45_psp_parser.a:m_pseudo_pwscf.o: 0000000000149940 D ___pseudo_pwscf_MOD_ecutrho
src/45_psp_parser/lib45_psp_parser.a:read_upf_pwscf.o: U ___pseudo_pwscf_MOD_ecutrho

I'm not exactly sure what the difference between a common symbol (C) and a data section symbol (D) is, or if that really matters. This issue seems to be a bug in the mac version of ifort or how abinit handles the pwscf module; I'm also using an older version of ifort in RHL and everything appears to work there. I don't currently have access to that machine so I can't upload any logs from it. I hope this information provides some clue on how to avoid or fix this bug.

Hello,

try with

FC_LDFLAGS_EXTRA="-Wl,-search_paths_first"

in the configure command

jmb

jbeuken wrote:Hello,

try with

FC_LDFLAGS_EXTRA="-Wl,-search_paths_first"

in the configure command

jmb

jmb,

Thanks for the suggestion. Unfortunately, I get the same error. However, it did inspire me to read the manual page for ld. I decided to try relinking lib45_psp_parser.a like so:

ld -d -r -o lib45_psp_parser.a flib_pwscf.o functionals_pwscf.o inpspheads.o m_pseudo_pwscf.o m_pseudo_types.o psxml2ab.o read_upf_pwscf.o upfheader2abi.o interfaces_45_psp_parser.o

The "-d" option claims to "force the definition of common symbols". This allowed the main program to link and so far, the executable appears to work! I don't know if this is a good solution, but I'm happy that it links and runs.

Thanks again for the suggestion! It certainly put me on the right path.
--liam

I've got the same problem with the compilation of abinit 6.2.2 using ifort 11.1.067 on Mac OS X 10.6.4.

Running, in the build directory,
$ ranlib -c src/01_qespresso_ext/lib01_qespresso_ext.a
solve the symbol definition error, but result in corrupt abinit executable.

However, if you upgrade to the latest version of ifort (11.1.089), this issue is solved (you still need to run ranlib, but the executable works). This looks related to a know incompatibility of the pre-11.1.089 ifort compiler with post-3.2.1 versions of Xcode :
http://software.intel.com/en-us/article ... xcode-322/

Yet, we still have some (8) tests that fail in test_acc.

Hope this helps.

I have had some similar problems, which come from the presence of several ld and ranlib in different paths on macosx: one from MacPorts and one from the XCode distrib. Try redefining your path such that it goes through /opt/local stuff first (or the other way around), and it should pick up the ld/libtool/ranlib/gfortran etc... that you actually want (having installed it yourself). They have to be compatible very specifically with the compiler you are using...

ciao

Matthieu

PS: macosx is not very intelligent in this way. A bit ridiculous I should have 3-4 different versions of gfortran/python/etc... on my system, and am unable to remove any of them without breaking something!

Please look at this post for complementary information:

viewtopic.php?f=2&t=598&p=1773#p1773