1 Reply Latest reply on Jan 11, 2013 3:14 PM by chipf

    Resolving ACML/gfortran version conflict?


      Hi.  An application I did not write but need to be able to edit/build from time to time has picked up a dependency on ACML.  I downloaded the latest version of ACML, installed it, set my build parameters/flags, and off I went . . .until I got lots and lots of of :


      /usr/local/lib/acml5.3.0/gfortran64_mp/lib/libacml_mp.a(xerbla.o): In function 'xerbla_':

      xerbla.f:(.txt+0x11c): undefined reference to '_gfortran_transfer_integer_write'

      (snip many more such errors)

      /usr/local/lib/acml5.3.0/gfortran64_mp/lib/libacml_mp.a(xerbla.o): In function 'xerbla_':

      xerbla.f:(.txt+0x556): undefined reference to '_gfortran_transfer_character_write'

      (again, snip many more such errors)


      I googled on this and found a discussion of such errors on this website, at http://devgurus.amd.com/thread/154719 , in which Chip Freitag from AMD suggests that the problem comes from ACML 5.0.0 (and presumably later versions like my recent d/l of 5.3.0) being built with gfortran 4.6.x.  Indeed, the gfortran we have installed is 4.4.3.  Mr. Freitag's post suggests as first option upgrading to a more recent version of the compiler; unfortunately, that option isn't available to me right now.  Which then points to Mr. Freitag's second option:  reverting to ACML v4.4.0.


      The problem is that AMD doesn't seem to make 4.4.0 available for download except in a 32-bit version.


      Older versions such as 3.6 are available in a 64-bit form for g77; but 4.4.0 for gfortran is only available as a 32-bit download.


      Is there another official source for 64-bit archival downloads?


      Alternately, is there another option anyone can suggest?


      Thanks very much for any help.

        • Re: Resolving ACML/gfortran version conflict?

          I had not responded to this since I thought the 4.4.0 archive was the right answer.  Another thread had info about the 4.4.0 64-bit version not being available, and we did resolve that issue.


          But I recently hit this problem myself, and it wasn't quite what I expected.


          I was doing some work on an Ubuntu system which has only GCC 4.6.3 installed and the associated gfortran.

          I linked ACML 5.3.0 libacml.so in a test program and all was well.  But then I linked in the static libacml.a, and I saw the classic _gfortran_compare_string etc. undefined externals from _xerbla.


          But I noticed that I could build the ACML examples on this machine with no problems, and it was using the static library!  So this couldn't be a simple matter of compiler version incompatibility.


          After  few tries I discovered that the order that libraries are included on the linker command line makes a difference.

          For instance

          gcc sgels_c_example.o -lgfortran -lm -ldl -lrt /opt/acml5.3.0/gfortran64/lib/libacml.a -o sgels_c_example.exe

          will cause the undefined externals.

          But putting the acml library first works!

          gcc sgels_c_example.o /opt/acml5.3.0/gfortran64/lib/libacml.a -lgfortran -lm -ldl -lrt -o sgels_c_example.exe


          Also using the shared library works.