Arpack build issue

[Keno]

I'm seeing this in the unit tests after the local_blas merge (Ubuntu 11.10 64bit):

/afs/ir.stanford.edu/users/k/e/kenof/julia/lib/libarpack.so: undefined symbol: pow_dd
could not load module libarpack
 in dlopen at base.jl:94
 in include at /afs/ir.stanford.edu/users/k/e/kenof/julia/src/boot.jl:198
at ../extras/arpack.jl:1
 in include at /afs/ir.stanford.edu/users/k/e/kenof/julia/src/boot.jl:198
at arpack.jl:1
 in include at /afs/ir.stanford.edu/users/k/e/kenof/julia/src/boot.jl:198
at default.jl:14
 in include at /afs/ir.stanford.edu/users/k/e/kenof/julia/src/boot.jl:198
at all.jl:1
 in load at util.jl:199
 in runtests at ./runtests.jl:3
 in include at /afs/ir.stanford.edu/users/k/e/kenof/julia/src/boot.jl:198
at ./runtests.jl:48
 in include at /afs/ir.stanford.edu/users/k/e/kenof/julia/src/boot.jl:198
make[1]: *** [all] Error 1
make: *** [testall] Error 2

[pao]

I didn't get that when I ran make testall this morning, same OS and 64bit, 8987c7e5d8071b0105ff70f9caa65a4b16b3e070. Have you tried blowing everything away (git clean -ndx, make sure the list looks right, then git clean -fdx to delete, then make from scratch)?

[Keno]

Yeah. I wiped the directory completely and did a new clone and build.

[Keno]

This is probably unrelated, but I just tried a complete rebuild and a parallel make fails from a clean checkout (probably due to a missing dependency in the Makefiles somewhere). Doing just a regular make works just fine.

sunif.c:45:42: fatal error: ../../random/dsfmt-2.1/dSFMT.h: No such file or directory

@ViralBShah or @pao Could you have a look at that.

[pao]

Already found that one, have the fix ready to go once the build runs through. I picked the wrong dependency when I fixed it this morning. Using a better one now.

EDIT: Just then, my VM crashed! It's past that part of the build, though, so I think we're safe.

[Keno]

Ok, greate. Anyway, the build just finished and this time I get

/afs/ir.stanford.edu/users/k/e/kenof/julia/usr/lib/libarpack.so: undefined symbol: s_wsfe
could not load module libarpack
 in dlopen at base.jl:94
 in include at /afs/ir.stanford.edu/users/k/e/kenof/julia/src/boot.jl:198
at ../extras/arpack.jl:1
 in include at /afs/ir.stanford.edu/users/k/e/kenof/julia/src/boot.jl:198
at arpack.jl:1
 in include at /afs/ir.stanford.edu/users/k/e/kenof/julia/src/boot.jl:198
at default.jl:14
 in include at /afs/ir.stanford.edu/users/k/e/kenof/julia/src/boot.jl:198
at all.jl:1
 in load at util.jl:199
 in runtests at ./runtests.jl:3
 in include at /afs/ir.stanford.edu/users/k/e/kenof/julia/src/boot.jl:198
at ./runtests.jl:48
 in include at /afs/ir.stanford.edu/users/k/e/kenof/julia/src/boot.jl:198
make[1]: *** [all] Error 1
make: *** [testall] Error 2

[pao]

Still compiling LLVM here...I'll let you know.

[Keno]

I retried just the arpack build and here's something interesting:

libtool: link: f77 -g -O2 -o .libs/dnsimp dnsimp.o mmio.o  ../.libs/libarpack.so -L/afs/ir.stanford.edu/users/k/e/kenof/julia/usr/lib -lopenblas -Wl,-rpath -Wl,/afs/ir.stanford.edu/users/k/e/kenof/julia/usr/lib
gcc: error: unrecognized option '-rpath'

Seems like it autodected f77 instead of gfortran. Might that be the problem?

[pao]

Possibly; from watching the build the compiler binary that's getting used on my machine is f951. I'm still having trouble building so I can't verify anything, though.

[pao]

Okay, finally. My tests are still coming out fine, so I'd suspect the compiler difference you noted. Not sure why that happens, though.

[Keno]

Maybe @ViralBShah can provide some insight

[pao]

Off-topic: Hopefully parallel builds are working properly again after 735cc6c70535ceb83966fcc8d00ce3b16023300d. I just did another clobber and only hit my usual out-of-memory problem. If you find something else go ahead and file a new issue.

[ViralBShah]

pow_dd sounds like a libgfortran linkage issue. What is the output of ldd libarpack.so or otool -L libarpack.dylib?

[Keno]

corn09:~/julia> ldd usr/lib/libarpack.so
        linux-vdso.so.1 =>  (0x00007ffff1dff000)
        libopenblas.so.0 => not found
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7f9b4d4000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f7f9baec000)
corn09:~/julia> ldd usr/lib/libopenblas.so
        linux-vdso.so.1 =>  (0x00007fff78be8000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa80bc61000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa80ba44000)
        libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3 (0x00007fa80b72d000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa80b38c000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fa80dc48000)
        libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007fa80b156000)

[ViralBShah]

Undefined pow_dd based on searching around seems to happen because of other fortran compilers. Do you have g77 installed by any chance? Perhaps in the arpack configure line, we should force and set the fortran compiler to $(FC) if that is indeed the problem.

[Keno]

Yeah, it's using f77 instead of gfortran.

[ViralBShah]

Ok, we just need to make the arpack configure accept something like F77=$(FC) or FC=$(FC). I won't be able to try this out for a couple of days though..

On Wed, May 2, 2012 at 6:55 PM, Keno Fischer reply@reply.github.com wrote:

Yeah, it's using f77 instead of gfortran.

---

Reply to this email directly or view it on GitHub: https://github.com/JuliaLang/julia/issues/780#issuecomment-5461248

-viral

[ViralBShah]

@loladiro Does the fix in commit 616d0dad29fa599dfb9b2acf036edd47d9464ca4 solve this problem?

[Keno]

Yeah, seems to work now. Thanks!