Another undefined reference to sgesv_ question...

[taylor]

Hi all,
I'm really struggling here trying to get LAPACK working on a remote computer that I use. Here's the lowdown:

There is no machine-specific BLAS library, so I'm using the librefblas.a (renamed to libblas.a) that is distributed with LAPACK.
I'm using make.inc.gfortran from the LAPACK's INSTALL directory and did not modify it (even though when I compile my fortran programs, I use the -std=f2003 option, but have found that this is not causing my problem).
When I compile my program, I include the flags -L(directory where libblas.a and liblapack.a are stored) -llapack -lblas, and I'm fairly sure they're being found, because earlier I would get errors that ld could not find the libraries, which no not appear, so i think I've linked thinks properly.

NONETHELESS, when I try to compile a test fortran program that invokes "call sgesv(....)", I get the well-known error:

/tmp/ccgzZTsI.o: In function `MAIN__':
read_grib.f:(.text+0x2b7e): undefined reference to `sgesv_'
collect2: ld returned 1 exit status

I have examined the output of nm liblapack.a | grep sgesv and find that the name of the function is indeed sgesv_
I'm a bit at a loss. Does anyone have any thoughts? Thank you for your help, in advance!
Taylor

[admin]

I would recompile LAPACK and BLAS without that -std=2003 option, just to be sure.
If the linking problem is still here that means the problem is in your program...
Could you post it please?
Julie

[Julien Langou]

Yep and you can do as well an nm of your read_grib.o and grep for sgesv and check that you see sgesv_ there as well (maybe a grep -i actually).
If you see it on both sides, make sure it is actually defined on the LAPACK side (not just called by the LAPACK side). Cheers, J.

[taylor]

Hi all, thanks for the tips! I have actually tried compiling the LAPACK abd BLAS libraries both ways already (with and without the -std=f2003 flag, though I can't get it to compile completely with that option because eventually it runs into a COMPLEX*16 type declaration, which f2003 doesn't like (even with the -fall-intrinsics option) and I get an error. Below I have posted a sample program that I'm trying this with (I actually just borrowed this sample from another online forum, but I get the same error as with my actual program):

program testlapack
implicit none

integer N
parameter(N=10)
integer NRHS
parameter(NRHS=1)
integer LDA
parameter(LDA=10)
integer IPIV(N)
integer LDB
parameter(LDB=N)
real A(LDA,N)
real B(LDB,NRHS)
integer INFO
external SGESV

call SGESV(N,NRHS,A,LDA,IPIV,B,LDB,INFO)
end

While I try to compile with:
gfortran -Wall -ffree-form -cpp -std=f2003 -L/home/***user***/lapack-3.4.0/ -llapack -lblas

I am unable to provide the output of nm read_grib.o because there is no output file generated. Compilation exits with an error. Unless I didn't understand the second point correctly. Thanks again for help!

[Julien Langou]

To get the .o, I think you just need to add a " -c " in your compilaton line, so that would give something like:

Code: Select all

gfortran -Wall -ffree-form -cpp -std=f2003 -c read_grib.f


this should give a .o file that you can then nm
Julien.

[taylor]

Oh, excellent, thank you. So many compiler options! No need to grep this, here is the entire output of nm test.o (using the test.f file provided above):

0000000000000000 t MAIN__
U _gfortran_set_args
U _gfortran_set_options
0000000000000058 T main
0000000000000020 r options.0.1552
U sgesv_

[Julien Langou]

OK .. this looks good on this side. So now what is the exact output of your "" nm lapack.a | grep -i SGESV "?

[taylor]

Hi, thank you for your replies! Do you mean what is the output of "nm liblapack.a | grep -i SGESV" ? There is no file titled lapack.a in my LAPACK directory. Should there be?

sgesv.o:
0000000000000000 T sgesv_
sgesvd.o:
0000000000000000 T sgesvd_
sgesvx.o:
0000000000000000 T sgesvx_
U sgesvj_
sgesvj.o:
0000000000000000 T sgesvj_
dsgesv.o:
0000000000000000 T dsgesv_

[Julien Langou]

Well ... you are sure you are linking against the same lapack library as you are "nm"ing ...
See the sgesv_ is there (in the lapack library), when you do nm, yet the linker does not find it.
It looks like there is a weird thing going on in your library paths.
Or maybe your linking sequence does something I do not understand.

More specifically if you did:

Code: Select all

nm /home/***user***/lapack-3.4.0/liblapack.a


and see

Code: Select all

sgesv.o:
0000000000000000 T sgesv_


that's all you need to have sgesv_ ...
And sgesv_ is what is needed on the other side so ...

Julien.

[taylor]

That's pesky. Thank you for your help, I'll speak to the system administrator after the weekend (all of this is done through a secure shell) and see if he has some insight. I'll keep you posted, but I really appreciate the help.
Taylor

[Julien Langou]

OK here is one more thing that you can try on your end:

Code: Select all

gfortran -Wall -ffree-form -cpp -std=f2003 read_grib.f /home/***user***/lapack-3.4.0/liblapack.a  /home/***user***/lapack-3.4.0/libblas.a


( So basically you give the explicit library path and avoid the -L... -l.... stuff, so that you are sure to use what you think you are using. )

Cheers,
Julien.

[taylor]

Hi. That's a good idea, but the same error occurs. Doesn't seem to make a difference. Strange!
Taylor

[taylor]

Hi again everyone,
I've spoke to the systems administrator and he's not sure either. I have now tried installing LAPACK on my own local system, an I GET THE SAME RESULT. So perhaps there is nothing wrong with the linker on the remote system, but I've done something wrong compiling the libraries. Let me summarize some of the specifics:

I installed the LAPACK libraries by first copying the make.inc.gfortran 'example makefile' into the lapack directoty as make.inc. I did not change any options or add any flags. Then:

make blaslib
make
cp librefblas.a libblas.a
make clean

To test the installation with a sample fortran program, I try compiling with:

gfortran -std=f2003 -cpp -ffree-form -Wall -L/path/to/lapack-3.4.0 -lblas -llapack test.f

and get the error (notice that I do not get an error telling me the -lblas or -llapack were not found):

/tmp/cc0MSk7O.o: In function `MAIN__':
test.f:(.text+0x53): undefined reference to `sgesv_'
collect2: ld returned 1 exit status

I have verified that the test.o file is referring to the same function as the liblapack.a file using:

nm test.o |grep -i sgesv
U sgesv_

and:

nm /path/to/lapack-3.4.0/liblapack.a | grep -i sgesv
sgesv.o:
0000000000000000 T sgesv_
sgesvd.o:
0000000000000000 T sgesvd_
sgesvx.o:
0000000000000000 T sgesvx_
U sgesvj_
sgesvj.o:
0000000000000000 T sgesvj_
dsgesv.o:
0000000000000000 T dsgesv_

I'm really at a loss here, and so is our systems admin. Any more thoughts? I have tried each of the suggestions in this forum on both machines, and get the same result. Thank you in advance!!
Taylor

[Julien Langou]

1) Avoid -L -l just to be on the safe side.

2) Then the lapack library needs to be given before the blas one.
So -llapack -lblas in your case, not the reverse.
Although this latter does not explain your problem.

[rodney]

Which version of gfortran are you using? Also, have you tried writing a very simple program that calls sgesv to see if that will link?

Rodney