Compiling abinit 6.0.x on Mac OS X 10.6.4 using ifort 11.1

HPC, IBM, Mac OS, Windows, ...

Moderators: jbeuken, Jordan, gmatteo

Forum rules
Please have a look at ~abinit/doc/config/build-config.ac in the source package for detailed and up-to-date information about the configuration of Abinit builds.
For a video explanation on how to build Abinit 7 for Linux, please go to: http://www.youtube.com/watch?v=DppLQ-KQA68.
IMPORTANT: when an answer solves your problem, please check the little green button on its upper-right corner to accept it.
Post Reply
ldamewood
Posts: 14
Joined: Tue Mar 09, 2010 11:39 pm

Compiling abinit 6.0.x on Mac OS X 10.6.4 using ifort 11.1

Post by ldamewood » Wed Jun 30, 2010 9:04 pm

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.
Attachments
configure.log
Log of "configure" command
(21.38 KiB) Downloaded 282 times

User avatar
jbeuken
Posts: 350
Joined: Tue Aug 18, 2009 9:24 pm
Contact:

Re: Compiling abinit 6.0.x on Mac OS X 10.6.4 using ifort 11

Post by jbeuken » Wed Jun 30, 2010 11:24 pm

Hello,

try with

FC_LDFLAGS_EXTRA="-Wl,-search_paths_first"

in the configure command

jmb
------
Jean-Michel Beuken
Computer Scientist

ldamewood
Posts: 14
Joined: Tue Mar 09, 2010 11:39 pm

Re: Compiling abinit 6.0.x on Mac OS X 10.6.4 using ifort 11

Post by ldamewood » Thu Jul 01, 2010 12:36 am

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

jolafc
Posts: 34
Joined: Wed Aug 26, 2009 5:37 am

Re: Compiling abinit 6.0.x on Mac OS X 10.6.4 using ifort 11

Post by jolafc » Mon Sep 20, 2010 9:18 pm

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.

mverstra
Posts: 652
Joined: Wed Aug 19, 2009 12:01 pm

Re: Compiling abinit 6.0.x on Mac OS X 10.6.4 using ifort 11

Post by mverstra » Wed Sep 22, 2010 4:30 pm

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
Matthieu Verstraete
University of Liege, Belgium

mverstra
Posts: 652
Joined: Wed Aug 19, 2009 12:01 pm

Re: Compiling abinit 6.0.x on Mac OS X 10.6.4 using ifort 11

Post by mverstra » Wed Sep 22, 2010 4:31 pm

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!
Matthieu Verstraete
University of Liege, Belgium

User avatar
pouillon
Posts: 650
Joined: Wed Aug 19, 2009 10:08 am
Location: Spain
Contact:

Re: Compiling abinit 6.0.x on Mac OS X 10.6.4 using ifort 11

Post by pouillon » Fri Sep 24, 2010 6:59 pm

Please look at this post for complementary information:

viewtopic.php?f=2&t=598&p=1773#p1773
Yann Pouillon
Simune Atomistics
Donostia-San Sebastián, Spain

Post Reply