Emanuel,
Thanks a lot, but this does not seem to help. As I have mentioned in my first email, gfortran is not installed as a part of acml libraries on the cluster in question (unlike some other installations where there is a /usr/local/acml3.6.0/gfortran64 directory). On the machine I am trying to use, gfortran seems to be a part of the standard gcc installation: /usr/lib/gcc/x86_64-redhat-linux/4.1.2/libgfortran.so -> ../../../../lib64/libgfortran.so.1.0.0 Yet trying g++ -L /usr/local/acml3.6.0/gnu64/lib -L /usr/lib/gcc/x86_64-redhat- linux/4.1.2/ -lacml -lacml_mv -lgfortran test.cpp produces exactly the same output as before :-( What am I missing? Is the acml installation I am trying to use actually unusable for compiling ALPS with? Should I try installing acml libraries locally? Sorry is these questions seem dumb -- I am a novice in these matters. Best,
Kirill
On Thursday 29 April 2010 13:11:51 Emanuel Gull wrote:
Hi,
this looks like you're forgetting to link gfortran. Please try
g++ -L /usr/local/acml3.6.0/gnu64/lib -lacml -lacml_mv -lgfortran
Emanuel
On Apr 29, 2010, at 4:07 PM, Kirill Shtengel wrote:
Matthias,
Here is the best I seem to be able to do with your test program:
[shtengel@gigio ~]$ g++ -L /usr/local/acml3.6.0/gnu64/lib -lacml -lacml_mv test.cpp /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `e_wsfi' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_stop' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_wsfe' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `e_rsfi' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_cmp' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `e_wsfe' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `z_abs' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `do_lio' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_wsle' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `z_sqrt' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_cat' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `c_sqrt' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_copy' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_rsfi' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `do_fio' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `z_exp' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `c_abs' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `e_wsle' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `c_exp' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_wsfi' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `i_indx' collect2: ld returned 1 exit status
Could someone please help me with these errors? What are the libraries I am still missing? The other installation of acml/blas/lapack libraries I have mentioned in my previous email does not work at all: the linker reports skipping these libraries as incompatible (?). Once again, any help will be greatly appreciated!
Kirill
On Monday 26 April 2010 21:45:23 Matthias Troyer wrote:
On 27 Apr 2010, at 04:19, Kirill Shtengel wrote:
Hello,
I wonder if anyone can help me with configuring/compiling ALPS-1.3.5 on a Linux machine with AMD Opteron Processor. My problem seems to be making the configuration routine see either acml or blas/lapack libraries. From what I can tell, there are two separate installations of acml/blas/lapack libraries, one is the set of ACML libraries:
...
Removing references to lapack (i.e. keeping only references to blas in the configuration options makes no difference whatsoever). In either case, I am getting " LAPACK support no" at the end of the configuration process, and subsequent use of make does not compile dmrg (which is what I intend to run). Any help or suggestions will be greatly appreciated!
Hi Kirill
The best way to figure out how to link LAPACL/BLAS is to write a test program:
extern "C" {void dgeev_();} int main() { dgeev_(); }
and try to compile this with the -L and -l options you mention above. You'll immediately see the linker errors, which might give you hints regarding libraries you need to link in addition. We can help you more if you tell us what happens when you try this.
Matthias
Hi,
(off the list to avoid bothering everybody)
please reverse the order:
g++ test.cpp -L /usr/local/acml3.6.0/gnu64/lib -L /usr/lib/gcc/x86_64-redhat-linux/4.1.2/ -lacml -lacml_mv -lgfortran
and if that doesn't work: your acml (which is prehistoric!) might be linked against a prehistoric g2c library
g++ test.cpp -L /usr/local/acml3.6.0/gnu64/lib -L /usr/lib/gcc/x86_64-redhat-linux/4.1.2/ -lacml -lacml_mv -lg2c
and if it still won't work, try adding the math lib g++ test.cpp -L /usr/local/acml3.6.0/gnu64/lib -L /usr/lib/gcc/x86_64-redhat-linux/4.1.2/ -lacml -lacml_mv -lg2c -lm
...and please tell me where you're stuck if that won't work.
Emanuel
On Apr 29, 2010, at 10:23 PM, Kirill Shtengel wrote:
Emanuel,
Thanks a lot, but this does not seem to help. As I have mentioned in my first email, gfortran is not installed as a part of acml libraries on the cluster in question (unlike some other installations where there is a /usr/local/acml3.6.0/gfortran64 directory). On the machine I am trying to use, gfortran seems to be a part of the standard gcc installation: /usr/lib/gcc/x86_64-redhat-linux/4.1.2/libgfortran.so -> ../../../../lib64/libgfortran.so.1.0.0 Yet trying g++ -L /usr/local/acml3.6.0/gnu64/lib -L /usr/lib/gcc/x86_64-redhat- linux/4.1.2/ -lacml -lacml_mv -lgfortran test.cpp produces exactly the same output as before :-( What am I missing? Is the acml installation I am trying to use actually unusable for compiling ALPS with? Should I try installing acml libraries locally? Sorry is these questions seem dumb -- I am a novice in these matters. Best,
Kirill
On Thursday 29 April 2010 13:11:51 Emanuel Gull wrote:
Hi,
this looks like you're forgetting to link gfortran. Please try
g++ -L /usr/local/acml3.6.0/gnu64/lib -lacml -lacml_mv -lgfortran
Emanuel
On Apr 29, 2010, at 4:07 PM, Kirill Shtengel wrote:
Matthias,
Here is the best I seem to be able to do with your test program:
[shtengel@gigio ~]$ g++ -L /usr/local/acml3.6.0/gnu64/lib -lacml -lacml_mv test.cpp /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `e_wsfi' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_stop' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_wsfe' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `e_rsfi' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_cmp' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `e_wsfe' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `z_abs' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `do_lio' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_wsle' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `z_sqrt' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_cat' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `c_sqrt' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_copy' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_rsfi' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `do_fio' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `z_exp' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `c_abs' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `e_wsle' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `c_exp' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_wsfi' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `i_indx' collect2: ld returned 1 exit status
Could someone please help me with these errors? What are the libraries I am still missing? The other installation of acml/blas/lapack libraries I have mentioned in my previous email does not work at all: the linker reports skipping these libraries as incompatible (?). Once again, any help will be greatly appreciated!
Kirill
On Monday 26 April 2010 21:45:23 Matthias Troyer wrote:
On 27 Apr 2010, at 04:19, Kirill Shtengel wrote:
Hello,
I wonder if anyone can help me with configuring/compiling ALPS-1.3.5 on a Linux machine with AMD Opteron Processor. My problem seems to be making the configuration routine see either acml or blas/lapack libraries. From what I can tell, there are two separate installations of acml/blas/lapack libraries, one is the set of ACML libraries:
...
Removing references to lapack (i.e. keeping only references to blas in the configuration options makes no difference whatsoever). In either case, I am getting " LAPACK support no" at the end of the configuration process, and subsequent use of make does not compile dmrg (which is what I intend to run). Any help or suggestions will be greatly appreciated!
Hi Kirill
The best way to figure out how to link LAPACL/BLAS is to write a test program:
extern "C" {void dgeev_();} int main() { dgeev_(); }
and try to compile this with the -L and -l options you mention above. You'll immediately see the linker errors, which might give you hints regarding libraries you need to link in addition. We can help you more if you tell us what happens when you try this.
Matthias
-- Kirill Shtengel Associate Professor Department of Physics & Astronomy UC Riverside, CA 92521 Tel: (951) 827-1058
OK, after some messing around, I could compile Matthias' test file by issuing this command: g++ test.cpp -L /usr/local/acml3.6.0/gnu64/lib -L /usr/lib/gcc/x86_64-redhat- linux/3.4.6/ -lacml -lacml_mv -lg2c
Now, I'm at loss how to tell the ALPS configuration routine to look for libg2c at /usr/lib/gcc/x86_64-redhat-linux/3.4.6/ , it does not seem there is an option for that. Any thoughts?
Kirill
On Thursday 29 April 2010 14:25:35 Emanuel Gull wrote:
Hi,
(off the list to avoid bothering everybody)
please reverse the order:
g++ test.cpp -L /usr/local/acml3.6.0/gnu64/lib -L /usr/lib/gcc/x86_64-redhat-linux/4.1.2/ -lacml -lacml_mv -lgfortran
and if that doesn't work: your acml (which is prehistoric!) might be linked against a prehistoric g2c library
g++ test.cpp -L /usr/local/acml3.6.0/gnu64/lib -L /usr/lib/gcc/x86_64-redhat-linux/4.1.2/ -lacml -lacml_mv -lg2c
and if it still won't work, try adding the math lib g++ test.cpp -L /usr/local/acml3.6.0/gnu64/lib -L /usr/lib/gcc/x86_64-redhat-linux/4.1.2/ -lacml -lacml_mv -lg2c -lm
...and please tell me where you're stuck if that won't work.
Emanuel
On Apr 29, 2010, at 10:23 PM, Kirill Shtengel wrote:
Emanuel,
Thanks a lot, but this does not seem to help. As I have mentioned in my first email, gfortran is not installed as a part of acml libraries on the cluster in question (unlike some other installations where there is a /usr/local/acml3.6.0/gfortran64 directory). On the machine I am trying to use, gfortran seems to be a part of the standard gcc installation: /usr/lib/gcc/x86_64-redhat-linux/4.1.2/libgfortran.so -> ../../../../lib64/libgfortran.so.1.0.0 Yet trying g++ -L /usr/local/acml3.6.0/gnu64/lib -L /usr/lib/gcc/x86_64-redhat- linux/4.1.2/ -lacml -lacml_mv -lgfortran test.cpp produces exactly the same output as before :-( What am I missing? Is the acml installation I am trying to use actually unusable for compiling ALPS with? Should I try installing acml libraries locally? Sorry is these questions seem dumb -- I am a novice in these matters. Best,
Kirill
On Thursday 29 April 2010 13:11:51 Emanuel Gull wrote:
Hi,
this looks like you're forgetting to link gfortran. Please try
g++ -L /usr/local/acml3.6.0/gnu64/lib -lacml -lacml_mv -lgfortran
Emanuel
On Apr 29, 2010, at 4:07 PM, Kirill Shtengel wrote:
Matthias,
Here is the best I seem to be able to do with your test program:
[shtengel@gigio ~]$ g++ -L /usr/local/acml3.6.0/gnu64/lib -lacml -lacml_mv test.cpp /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `e_wsfi' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_stop' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_wsfe' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `e_rsfi' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_cmp' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `e_wsfe' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `z_abs' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `do_lio' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_wsle' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `z_sqrt' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_cat' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `c_sqrt' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_copy' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_rsfi' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `do_fio' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `z_exp' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `c_abs' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `e_wsle' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `c_exp' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_wsfi' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `i_indx' collect2: ld returned 1 exit status
Could someone please help me with these errors? What are the libraries I am still missing? The other installation of acml/blas/lapack libraries I have mentioned in my previous email does not work at all: the linker reports skipping these libraries as incompatible (?). Once again, any help will be greatly appreciated!
Kirill
On Monday 26 April 2010 21:45:23 Matthias Troyer wrote:
On 27 Apr 2010, at 04:19, Kirill Shtengel wrote:
Hello,
I wonder if anyone can help me with configuring/compiling ALPS-1.3.5 on a Linux machine with AMD Opteron Processor. My problem seems to be making the configuration routine see either acml or blas/lapack libraries. From what I can tell, there are two separate installations of acml/blas/lapack libraries, one is the set of ACML libraries:
...
Removing references to lapack (i.e. keeping only references to blas in the configuration options makes no difference whatsoever). In either case, I am getting " LAPACK support no" at the end of the configuration process, and subsequent use of make does not compile dmrg (which is what I intend to run). Any help or suggestions will be greatly appreciated!
Hi Kirill
The best way to figure out how to link LAPACL/BLAS is to write a test program:
extern "C" {void dgeev_();} int main() { dgeev_(); }
and try to compile this with the -L and -l options you mention above. You'll immediately see the linker errors, which might give you hints regarding libraries you need to link in addition. We can help you more if you tell us what happens when you try this.
Matthias
Hi Kirill,
let me suggest the way that will be easiest to port to ALPS2.0. What yu do is you add the following to the ALPS configure command:
--with-blas="/usr/local/acml3.6.0/gnu64/lib/libacml.so /usr/local/acml3.6.0/gnu64/lib/libacml_mv.so /usr/lib/gcc/x86_64-redhat-linux/3.4.6/libg2c.a"
where you need to check whether those three files actually have the suffixes I just guesses here
Matthias
On Apr 30, 2010, at 1:39 AM, Kirill Shtengel wrote:
OK, after some messing around, I could compile Matthias' test file by issuing this command: g++ test.cpp -L /usr/local/acml3.6.0/gnu64/lib -L /usr/lib/gcc/x86_64-redhat- linux/3.4.6/ -lacml -lacml_mv -lg2c
Now, I'm at loss how to tell the ALPS configuration routine to look for libg2c at /usr/lib/gcc/x86_64-redhat-linux/3.4.6/ , it does not seem there is an option for that. Any thoughts?
Kirill
On Thursday 29 April 2010 14:25:35 Emanuel Gull wrote:
Hi,
(off the list to avoid bothering everybody)
please reverse the order:
g++ test.cpp -L /usr/local/acml3.6.0/gnu64/lib -L /usr/lib/gcc/x86_64-redhat-linux/4.1.2/ -lacml -lacml_mv -lgfortran
and if that doesn't work: your acml (which is prehistoric!) might be linked against a prehistoric g2c library
g++ test.cpp -L /usr/local/acml3.6.0/gnu64/lib -L /usr/lib/gcc/x86_64-redhat-linux/4.1.2/ -lacml -lacml_mv -lg2c
and if it still won't work, try adding the math lib g++ test.cpp -L /usr/local/acml3.6.0/gnu64/lib -L /usr/lib/gcc/x86_64-redhat-linux/4.1.2/ -lacml -lacml_mv -lg2c -lm
...and please tell me where you're stuck if that won't work.
Emanuel
On Apr 29, 2010, at 10:23 PM, Kirill Shtengel wrote:
Emanuel,
Thanks a lot, but this does not seem to help. As I have mentioned in my first email, gfortran is not installed as a part of acml libraries on the cluster in question (unlike some other installations where there is a /usr/local/acml3.6.0/gfortran64 directory). On the machine I am trying to use, gfortran seems to be a part of the standard gcc installation: /usr/lib/gcc/x86_64-redhat-linux/4.1.2/libgfortran.so -> ../../../../lib64/libgfortran.so.1.0.0 Yet trying g++ -L /usr/local/acml3.6.0/gnu64/lib -L /usr/lib/gcc/x86_64-redhat- linux/4.1.2/ -lacml -lacml_mv -lgfortran test.cpp produces exactly the same output as before :-( What am I missing? Is the acml installation I am trying to use actually unusable for compiling ALPS with? Should I try installing acml libraries locally? Sorry is these questions seem dumb -- I am a novice in these matters. Best,
Kirill
On Thursday 29 April 2010 13:11:51 Emanuel Gull wrote:
Hi,
this looks like you're forgetting to link gfortran. Please try
g++ -L /usr/local/acml3.6.0/gnu64/lib -lacml -lacml_mv -lgfortran
Emanuel
On Apr 29, 2010, at 4:07 PM, Kirill Shtengel wrote:
Matthias,
Here is the best I seem to be able to do with your test program:
[shtengel@gigio ~]$ g++ -L /usr/local/acml3.6.0/gnu64/lib -lacml -lacml_mv test.cpp /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `e_wsfi' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_stop' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_wsfe' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `e_rsfi' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_cmp' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `e_wsfe' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `z_abs' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `do_lio' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_wsle' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `z_sqrt' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_cat' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `c_sqrt' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_copy' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_rsfi' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `do_fio' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `z_exp' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `c_abs' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `e_wsle' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `c_exp' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_wsfi' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `i_indx' collect2: ld returned 1 exit status
Could someone please help me with these errors? What are the libraries I am still missing? The other installation of acml/blas/lapack libraries I have mentioned in my previous email does not work at all: the linker reports skipping these libraries as incompatible (?). Once again, any help will be greatly appreciated!
Kirill
On Monday 26 April 2010 21:45:23 Matthias Troyer wrote:
On 27 Apr 2010, at 04:19, Kirill Shtengel wrote: > Hello, > > I wonder if anyone can help me with configuring/compiling ALPS-1.3.5 > on a Linux machine with AMD Opteron Processor. My problem seems to be > making the configuration routine see either acml or blas/lapack > libraries. From what I can tell, there are two separate installations > of > acml/blas/lapack libraries, one is the set of ACML libraries:
...
> Removing references to lapack (i.e. keeping only references to blas > in the configuration options makes no difference whatsoever). In > either case, I am getting " LAPACK support no" at the end of > the configuration process, and subsequent use of make does not > compile dmrg (which is what I intend to run). > Any help or suggestions will be greatly appreciated!
Hi Kirill
The best way to figure out how to link LAPACL/BLAS is to write a test program:
extern "C" {void dgeev_();} int main() { dgeev_(); }
and try to compile this with the -L and -l options you mention above. You'll immediately see the linker errors, which might give you hints regarding libraries you need to link in addition. We can help you more if you tell us what happens when you try this.
Matthias
-- Kirill Shtengel Associate Professor Department of Physics & Astronomy UC Riverside, CA 92521 Tel: (951) 827-1058
Dear Kirill,
As Emanuel writes, these are indeed functions of the Fortran runtime libraries. This is not an issue with ALPS but a general ACML issue on your machine, completely independent from ALPS. Do you manage the machine yourself or is there a system administrator? The system administrator should be able to tell you where the Fortran runtime libraries are. Maybe they come with some other Fortran compiler.
Do you maybe have a libg2c instead of the libgfortran?
Googling the AMD web pages many people seems to have problems finding the right combination of fotran libraries and ACML that work.
Looking at the manual at AMD's web page I can only find the 4.1 manual and that says:
-L/opt/acml4.1.0/gfortran64/lib -lacml -lgfortran
The 4.4 manual similary:
gcc -m64 ... -L/opt/acml4.4.0/gfortran64/lib -lacml -lgfortran
You seems to have a non-standard ACML installation on your machine - please ask your system administrator.
Matthias
On 29 Apr 2010, at 23:23, Kirill Shtengel wrote:
Emanuel,
Thanks a lot, but this does not seem to help. As I have mentioned in my first email, gfortran is not installed as a part of acml libraries on the cluster in question (unlike some other installations where there is a /usr/local/acml3.6.0/gfortran64 directory). On the machine I am trying to use, gfortran seems to be a part of the standard gcc installation: /usr/lib/gcc/x86_64-redhat-linux/4.1.2/libgfortran.so -> ../../../../lib64/libgfortran.so.1.0.0 Yet trying g++ -L /usr/local/acml3.6.0/gnu64/lib -L /usr/lib/gcc/x86_64-redhat- linux/4.1.2/ -lacml -lacml_mv -lgfortran test.cpp produces exactly the same output as before :-( What am I missing? Is the acml installation I am trying to use actually unusable for compiling ALPS with? Should I try installing acml libraries locally? Sorry is these questions seem dumb -- I am a novice in these matters. Best,
Kirill
On Thursday 29 April 2010 13:11:51 Emanuel Gull wrote:
Hi,
this looks like you're forgetting to link gfortran. Please try
g++ -L /usr/local/acml3.6.0/gnu64/lib -lacml -lacml_mv -lgfortran
Emanuel
On Apr 29, 2010, at 4:07 PM, Kirill Shtengel wrote:
Matthias,
Here is the best I seem to be able to do with your test program:
[shtengel@gigio ~]$ g++ -L /usr/local/acml3.6.0/gnu64/lib -lacml -lacml_mv test.cpp /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `e_wsfi' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_stop' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_wsfe' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `e_rsfi' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_cmp' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `e_wsfe' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `z_abs' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `do_lio' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_wsle' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `z_sqrt' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_cat' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `c_sqrt' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_copy' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_rsfi' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `do_fio' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `z_exp' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `c_abs' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `e_wsle' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `c_exp' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `s_wsfi' /usr/local/acml3.6.0/gnu64/lib/libacml.so: undefined reference to `i_indx' collect2: ld returned 1 exit status
Could someone please help me with these errors? What are the libraries I am still missing? The other installation of acml/blas/lapack libraries I have mentioned in my previous email does not work at all: the linker reports skipping these libraries as incompatible (?). Once again, any help will be greatly appreciated!
Kirill
On Monday 26 April 2010 21:45:23 Matthias Troyer wrote:
On 27 Apr 2010, at 04:19, Kirill Shtengel wrote:
Hello,
I wonder if anyone can help me with configuring/compiling ALPS-1.3.5 on a Linux machine with AMD Opteron Processor. My problem seems to be making the configuration routine see either acml or blas/lapack libraries. From what I can tell, there are two separate installations of acml/blas/lapack libraries, one is the set of ACML libraries:
...
Removing references to lapack (i.e. keeping only references to blas in the configuration options makes no difference whatsoever). In either case, I am getting " LAPACK support no" at the end of the configuration process, and subsequent use of make does not compile dmrg (which is what I intend to run). Any help or suggestions will be greatly appreciated!
Hi Kirill
The best way to figure out how to link LAPACL/BLAS is to write a test program:
extern "C" {void dgeev_();} int main() { dgeev_(); }
and try to compile this with the -L and -l options you mention above. You'll immediately see the linker errors, which might give you hints regarding libraries you need to link in addition. We can help you more if you tell us what happens when you try this.
Matthias
-- Kirill Shtengel Associate Professor Department of Physics & Astronomy UC Riverside, CA 92521 Tel: (951) 827-1058
comp-phys-alps-users@lists.phys.ethz.ch