so I'm wondering if the download page should mention which version of gfortran is compatible. Also, since older gfortrans are really buggy and not recommended, are there plans to upgrade the acml libraries available ?

the problem with _gfortran_copy_string is a remainder from early days, I think. I also encountered the same problem with gfortran 4.2.1 under suse 10.3 and ACML 3.6.

The lapack routine ILAENV causes the trouble. In the libacml.a there is the symbol addressed which copies a string from one location to another. In the newer gfortran this is now done by the call memcopy which is general and is possibly located in the libgfortran or even libc. I deleted the llaenv.o and ilaenvkernel.o from libacml.a via "ar" and separately compiled ilaenv. This is an highly unprofessional solution but it works. One can see that now only memcopy calls occur. AMD should correct for that because it is not in line with the new gfortran and causes pain for the less experienced user who will NEVER be able to create a working executable.

And: For some strange reason the ACML was NOT faster than the generic LAPACKs and the code was 20 (!) times slower than the one compiled with PGI and ACML :-(

The gfortran ACML libraries are currently built with two different GCC/GFORTRAN compilers.

The SINGLE THREADED libraries found in /opt/gfortran64 and /opt/gfortran64_int64 are built with 4.1.2. This compiler version is used because it is the most widely supported compiler with most new linux distributions (or was in 2007).

The OpenMP MULTI THREADED libraries found in /opt/gfortran64_mp and /opt/gfortran64_mp_int64 are built with 4.2.0. This compiler is used because it was finally released in 2007 and 4.1.2 does not natively support OpenMP.

This is mentioned in the release notes, but it's obvious not very clear.

When using GCC/GFORTRAN 4.3, you will likely need to use the mp versions of the library. This has not been tested by AMD. When 4.3 releases, AMD may provide a 4.3 build.

This issue happens because of the incompatibility between GCC 4.1.2 and 4.2. Now that more distributions are supplying GCC 4.2 AMD may only support GCC 4.2 for 2008 releases. In other words, no more 4.1.2 builds. Both single- and multi-threaded libraries would be built with 4.2. Any feedback on this plan is greatly appreciated.

It is indeed unfortunate that the gcc people so carelessly changed the fortran run-time library interfaces between releases. However even your plan to compile with 4.2 means that ACML is useless to me with gfortran. My application (the electronic structure code CASTEP does not compile under gfortran 4.1 or 4.2, and only 4.3.0 is sufficiently developed.

As an earlier poster pointed out the parts of LAPACK which call the fortran RTL are very restricted, and mostly confined to ILAENV. My suggestion is to rewrite this in a non-portable fashion, probably using the C interop stuff to call the more stable C API for string copy, and thereby eliminate the troublesome fortran RTL dependencies. I would guess this would not be much more effort than supporting multiple versions of gfortran - perhaps even less.

Regarding the library incompatibilty problem, there is good news for the future: Starting from GCC 4.3.0 the libgfortran library uses versioned symbols which means that on systems which support it (such as Linux), GCC 4.3.0 compiled libraries will also work with later GCCs as no symbol will be removed and the versioning allows even interface changes which does not affect older versions.

Unfortunately, this does not help with the compatibility between GCC 4.1 (which uses libgfortran.so.1), GCC 4.2 (which uses libgfortran.so.2) and GCC 4.3/4.4 (which use libgfortran.so.3).

In general, GCC 4.3.x is the best GCC with regards to Fortran and it will be the default compiler for many Linux systems ([open]SUSE, Fedrora/Red Hat, Debian, ...). GCC 4.1 was quite widely used but misses OpenMP (except in the Red Hat version) and GCC 4.2 was not as widely used. (GCC 4.3 has also the advantage that several bugs have been fixed, features added and that it is faster.)

Another cool thing in GCC 4.3:

gcc/g++/gfortran: Use -mveclibabi=acml to automatically use the vectorized trigonometric functions etc. of AMCL

gfortran: Use -fexternal-blas together with ACML to speed up matrix multiplications

I have niticed this incompatibility between ACML 4.1.0 and gfortran 4.3.1. I have managed to eliminate the missing references by downgrading libgfortran from libgfortran.so.3.0.0 to libgfortran.so.2.0.0