On Mon, 2 Apr 2007, Nicolas Tetreault wrote:
gcc -g -O2 -o harminv
harminv-main.o
/usr/local/Cluster-Apps/intel/mkl/9.0.018/lib/em64t/libmkl_lapack32.so
/usr/local/Cluster-Apps/intel/mkl/9.0.018/lib/em64t/libmkl.so
-L/home/nt271/comp-apps/para/lib ./.libs/libharminv.a
-L/usr/lib/gcc/x86_64-redhat-linux/3.4.5
-L/usr/lib/gcc/x86_64-redhat-linux/3.4.5/../../../../lib64
-L/usr/lib/gcc/x86_64-redhat-linux/3.4.5/../../.. -L/lib/../lib64
-L/usr/lib/../lib64 -lfrtbegin -lg2c -lm -lgcc_s
./.libs/libharminv.a(harminv.o)(.text+0x2114): In function
`solve_eigenvects':
/home/nt271/temp/harminv-1.3.1/harminv.c:497: undefined reference to
`zgeev_'
collect2: ld returned 1 exit status
The problem here is that the LAPACK etc. libraries need to be listed
after libharminv.a on the command line. Which they normally are...
I'm guessing that you specified the location of your LAPACK library in a
funny way. Did you do
./configure --with-lapack=<lib>
?
harminv-main.o harminv-main.c
-I/usr/local/Cluster-Apps/infinipath/2.0/if-mpi/include/
harminv-main.c(126): error: floating-point operation result is out of
range
const double inf = 1.0 / 0.0;
Yes, I noticed recently that some compilers seem to complain about this,
for no good reason as far as I can tell. (1.0 / 0.0 is perfectly well
defined in IEEE 754 floating-point arithmetic -- it gives Inf -- and this
is supported by all modern CPUs.)
However, to keep the compiler from complaining you can just replace 1.0 /
0.0 with 1e100 here.
Steven
_______________________________________________
meep-discuss mailing list
[email protected]
http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
