Another undefined reference to sgesv_ question...

[taylor]

Thanks for your replies.

I am now compiling using the much simpler:

gfortran /path/to/lapack-3.4.0/liblapack.a /path/to/lapack-3.4.0/libblas.a test.f

...where test.f is simply:

program testlapack
call sgesv() ! I shouldn't have to provide args here just to test if it links
end

I am using GNU Fortran (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1

Same compilation error:
/tmp/ccyu8mjk.o: In function `MAIN__':
test2.f:(.text+0xa): undefined reference to `sgesv_'
collect2: ld returned 1 exit status

[Julien Langou]

You know what, you should start getting totally frustrated at this point ...

OK so one more step down the ladder ....
(The next one I think is to copy-paste sgesv code in your main .... No kidding!)

Try:

Code: Select all

gfortran  -c test.f
gfortran  test.o   /path/to/lapack-3.4.0/SRC/sgesv.o


The linker will miss some reference for sure. Does it get sgesv_ at least here?

J

[taylor]

Also, interestingly, if I append the flag -c to my compilation command I get the following errors

gfortran: warning: /home/binningtont/lapack-3.4.0/liblapack.a: linker input file unused because linking not done
gfortran: warning: /home/binningtont/lapack-3.4.0/libblas.a: linker input file unused because linking not done

Interesting? I guess we sort of knew that though...

[Julien Langou]

Also, interestingly, if I append the flag -c to my compilation command I get the following errors

gfortran: warning: /home/binningtont/lapack-3.4.0/liblapack.a: linker input file unused because linking not done
gfortran: warning: /home/binningtont/lapack-3.4.0/libblas.a: linker input file unused because linking not done

Interesting? I guess we sort of knew that though...

Well but that's correct behavior here. If you add -c, you are asking gfortran to compile (as opposed to link). So gfortran creates the .o file, (since there is a -c), and then really wonder why you gives him/her some .a file. So that's correct behavior here.

[taylor]

Okay I tried the above suggestion:

gfortran -c test.f
gfortran test.o /path/to/lapack-3.4.0/SRC/sgesv.o

...which tells me that there is no such file or directory as sgesv.o!!!

I looked into the directory, and sure enough, there were no *.o files there, only *.f files. I Could see the sgesv.f file. I thought this may be due to my typing 'make clean' after compiling the libraries, so I recompiled them without the make clean, and tried again.

gfortran -c test.f
gfortran test.o /path/to/lapack-3.4.0/SRC/sgesv.o

This gives me the errors:

sgesv.f:(.text+0x91): undefined reference to `xerbla_'
sgesv.f:(.text+0xdf): undefined reference to `sgetrf_'
sgesv.f:(.text+0x122): undefined reference to `sgetrs_'
collect2: ld returned 1 exit status

So I manually added these to my command, by typing:

gfortran test2.o /home/binningtont/lapack-3.4.0/SRC/sgesv.o /home/binningtont/lapack-3.4.0/SRC/xerbla.o /home/binningtont/lapack-3.4.0/SRC/sgetrf.o /home/binningtont/lapack-3.4.0/SRC/sgetrs.o

Which gives me:

/home/binningtont/lapack-3.4.0/SRC/sgetrf.o: In function `sgetrf_':
sgetrf.f:(.text+0xf3): undefined reference to `ilaenv_'
sgetrf.f:(.text+0x1bd): undefined reference to `sgetf2_'
sgetrf.f:(.text+0x267): undefined reference to `slaswp_'
sgetrf.f:(.text+0x320): undefined reference to `slaswp_'
sgetrf.f:(.text+0x3d0): undefined reference to `strsm_'
sgetrf.f:(.text+0x4ac): undefined reference to `sgemm_'
sgetrf.f:(.text+0x4ed): undefined reference to `sgetf2_'
/home/binningtont/lapack-3.4.0/SRC/sgetrs.o: In function `sgetrs_':
sgetrs.f:(.text+0x5d): undefined reference to `lsame_'
sgetrs.f:(.text+0x18b): undefined reference to `strsm_'
sgetrs.f:(.text+0x1fd): undefined reference to `strsm_'
sgetrs.f:(.text+0x22c): undefined reference to `slaswp_'
sgetrs.f:(.text+0x24d): undefined reference to `lsame_'
sgetrs.f:(.text+0x26c): undefined reference to `lsame_'
sgetrs.f:(.text+0x303): undefined reference to `slaswp_'
sgetrs.f:(.text+0x375): undefined reference to `strsm_'
sgetrs.f:(.text+0x3e7): undefined reference to `strsm_'
collect2: ld returned 1 exit status

So clearly I'm not adding all these, but you can see how this is going. Why might this be happening? Thanks again, you're a big help!

[Julien Langou]

So this means to me that your archive (liblapack.a) is badly set up and gfortran does not manage to parse it.
This happened to me in the past, I forgot why actually. I think this was the ran lib that messed everything up.

So well, now try to create an archive ....

Code: Select all

% in the LAPACK/SRC directory
ar -cr liblapacktest.a sgesv.o xerbla.o
% then with your code
gfortran test.o /path/to/lapack-3.4.0/SRC/liblapacktest.a


You should only be missing sgetrf_ and sgetrs_
If that's the case, you are on a good track.
Then:

Code: Select all

% in the LAPACK/SRC directory
ar -cr liblapack.a *.o


Same in the BLAS/SRC directory. Then try this ....

In the make.inc file of LAPACK, if you replace ranlib by echo for example. Then make clean / make. Then try linking again. Should work as well.

Julien.

[taylor]

Thank you. The first part of your comment was successful, meaning I was able to create the test library file contains two *.o files, which left only two undefined references to functions (the ones I hadn't ar -cr 'ed). So this was encouraging. What I then did was, in the /SRC directory:

ar -cr liblapack.a *.o

...and in the /BLAS/SRC directory:

ar -cr libblas.a *.o

Then I edited the make.inc file so that RANLIB = echo, and moved the two *.a library files that I had manually created into the root lapack-3.4.0/ directory. I expected that these would not be overwritten when I type make again, because I had removed the ranlib functionality. Then I typed:

make clean
make blaslib
make

I then tried to compile with

gortran /path/to/lapack-3.4.0/liblapack.a /path/to/lapack-3.4.0/libblas.a test.f

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

Okay, I thought, maybe my manually create libraries WERE overwritten somehow, so I manually created them again frm the *.o files in /SRC and /BLAS/SRC, and tried compiling with

gortran /path/to/lapack-3.4.0/SRC/liblapack.a /path/to/lapack-3.4.0/BLAS/SRC/libblas.a test.f

Same error as above, it made no difference. As a final try, I entered:

gfortran -c test.f
gfortran test.o /path/to/lapack-3.4.0/SRC/liblapack.a /path/to/lapack-3.4.0/BLAS/SRC/libblas.a

Which gives me a slightly different, but similar error:

/home/binningtont/lapack-3.4.0/SRC/liblapack.a(sgetf2.o): In function `sgetf2_':
sgetf2.f:(.text+0x10d): undefined reference to `slamch_'
collect2: ld returned 1 exit status

So I feel like we/you are on the right track, but it still isn't there yet. Am I missing some kind of THIRD library that I should be linking to, where slamch_ might be contained? libtmg.a or something? Super duper appreciated!
And as a sidenote, once I (theoretically) correctly create lib*.a files, I can then make clean to get rid of the *.o files form which they were made, right?

[rodney]

There are also a few files in the INSTALL directory (like slamch) that need to be in liblapack.a as well. If you look in SRC/Makefile, theses are listed in ALLAUX...

Rodney

[taylor]

Thanks for the reply. I recreated liblapack.a in the lapack directory using

ar -cr liblapack.a /path/to/lapack-3.4.0/SRC/*.o /path/to/lapack-3.4.0/INSTALL/*.o

Trying to compile:

gfortran /path/to/lapack-3.4.0/liblapack.a /path/to/lapack-3.4.0/libblas.a test2.f

...gives this:

test2.o: In function `main':
test2.f:(.text+0x10): multiple definition of `main'
/home/binningtont/lapack-3.4.0/liblapack.a(dlamchtst.o):dlamchtst.f:(.text.startup+0x0): first defined here
test2.o: In function `MAIN__':
test2.f:(.text+0xa): undefined reference to `sgesv_'
collect2: ld returned 1 exit status

Going the route of first creating the object file and linking it afterwards (like in the previous post) gives me this error:

/home/binningtont/lapack-3.4.0/liblapack.a(tstiee.o): In function `main':
tstiee.f:(.text.startup+0x0): multiple definition of `main'
test2.o:test2.f:(.text+0x10): first defined here
collect2: ld returned 1 exit status

Thanks for being patient. This is becoming annoying.

[Julien Langou]

There are also a few files in the INSTALL directory (like slamch) that need to be in liblapack.a as well. If you look in SRC/Makefile, theses are listed in ALLAUX...

"oh what fun it is ... "
Look like you are getting closer ..

Look at Rodney's email: Just take the ones in ALLAUX !!! the "*" take them all. Some of the .o are some mains. This is not appropriate.
So just the ones in ALLAUX.

When you have time, try to replace ranlib by echo in make.inc and recompile everything.
Just to see. It should work. I think your ranlib command messed up archives.

Julien.

[taylor]

Right, I had earlier replaced ranlib with echo. But I'll now make cleanall and start again from scratch including specifically (and only) those object files in the INSTALL directory that are mentioned in the /SRC/Makefile. I'll let you know how it goes in a bit.

[taylor]

Alright. So get this...

I started again from scratch, after having replaced ranlib with echo. Before even having to manually ar -cr anything, (just for the heck of it) I entered:

gfortran test.f -L/path/to/lapack-3.4.0/ -llapack -lblas

...and my program compiled. Then, using the simple test code here as my test program, I did the same thing, ran the program, and got the output I expected. However, when I run this slightly different command, as I have been all the while:

gfortran -L/path/to/lapack-3.4.0/ -llapack -lblas test.f

I get the familiar error:

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

So. I guess it never occurred to me that this would make a difference, and who knows how long ago (how far back in this thread) I could have tried that and it would have worked. I'd rather not know, frankly. But I want to thank you both for all your help, you've been fantastic. Is this not unusual behaviour though? Why should it matter where in the flag sequence the linking commands are? In the past, I've linked libraries before entering the name of the program to be compiled, and it's worked fine (also very convenient, since I can just alias a big long string of flags and links into a simple command like "gfort", and then type gfort test.f). Any final thoughts? Thank you so much, again!

[rodney]

OK, let's try another approach. Forget about building the library, and just get the source files for the routine(s) you need in your application, and compile together with your application. You can download a file + its depedencies from http://www.netlib.org/lapack/explore-html/, and in particular for sgesv from http://www.netlib.org/lapack/explore-html/d0/db8/group__real_g_esolve.html#ga214c4ef05c832f1391149489a2d6dabe

There are options to download tgz, zip or txt. Download the zip version, unzip it will contain the necessary source files inside of directories.

Rodney

[taylor]

Hm! I guess we could go that route, means it isn't very portable though. I'll try it, for interest, but when it comes to weighing the difficulty of getting the source for each desired function and manually including it, vs not being able to alias my gfortran compilation command (so as to ensure the linking flags come after the reference to the fortran program, so whatever reason), then I would probably take the latter.
Thank you for your help!!!