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.
I am working with the official gcc 4.3.0 release right now and the problem is still present: missing objects when using ACML 4.0.1 together with gfortran 4.3:
libacml_mp.so: undefined reference to `_gfortran_pow_r8_i4'
libacml_mp.so: undefined reference to `_gfortran_internal_free'
libacml_mp.so: undefined reference to `_gfortran_deallocate'
libacml_mp.so: undefined reference to `_gfortran_allocate64'
libacml_mp.so: undefined reference to `_gfortran_pow_r4_i4
libacml.so: undefined reference to `_gfortran_pow_r8_i4'
libacml.so: undefined reference to `_gfortran_copy_string'
libacml.so: undefined reference to `_gfortran_internal_free'
libacml.so: undefined reference to `_gfortran_deallocate'
libacml.so: undefined reference to `_gfortran_allocate64'
libacml.so: undefined reference to `_gfortran_pow_r4_i4'
The official GCC release has been out for over a month now. It would be great if you AMD developers could issue an ACML version which can be used together with gfortran 4.3. At the moment I'm stuck.
I'd be very interested in the release date is (days/weeks/months from now?). Please AMD developers give me a hint on how long I have to wait.
I also would like to see an ACML build for GCC 4.3.0.
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
FYI Material Studio has CASTEP already built in ready to go if you have it. Here in the US we can't get CASTEP source, I see your from the UK and thus have access (lucky).
I would use the PGI or Intel compilers, while gfortran is a big big step in the right direction, I tend to still avoid it.
If you have a lot of trouble you could use GOTO blas, or Atlas, though if your using Barcelonas you want acml/4.1 or higher.
Any news yet about gfortran 4.3.x support?
The latest version of ACML, 4.2.0, which was released in November, was built with GCC/GFORTRAN 4.3.2.
You can find that version on the ACML download pages.
I'm trying to compile the acmlg examples but similar error accurs:
../lib/libacml.a(dgemmwrapL.o): In function `dgemmwrapl_':
dgemmwrapL.F:(.text+0x197): undefined reference to `_gfortran_allocate64'
dgemmwrapL.F:(.text+0x1d6): undefined reference to `_gfortran_internal_free'
dgemmwrapL.F:(.text+0x37c): undefined reference to `_gfortran_deallocate'
I'm using gfortran 4.3.3 and ACML 4.2.0.
Can someone confirm that acml should now work with fortran 4.3.x (which would mean that the problem concerns my box...^^) ?
Edit: Turned off parsing of emoticons.
The latest post on ACML-GPU might be better off in one of the other forums, but the problem you're having is very similar to those described in this thread.
The problem is that ACML-GPU is built with, and requires, GCC/GFORTRAN 4.1.2. This is due to the requirements of the Stream SDK runtime libraries.
It would be great to get ACML-GPU, Stream SDK, OpenCL, etc all on the same compatibility level with the latest version of the GNU Compiler Collection, incuding gfortran 4.3.