Not using functions out of external libraries

[Francis_P_1]

OK, I'm having issues getting ifort to pull in functions out of libraries that weren't included in the intel package.

I had these issues with a copy of the BLAS library I compiled with ifort, but I ended up working around that using mkl.

However, this library I can't work around.    I'm sure it's something I'm doing wrong, or is wrong in the environment.   

I know the function is there in the library, 

nm -g libwsmp64.a | grep wgsmp

wgsmp.o:

0000000000001410 T wgsmp

0000000000000000 T wgsmp_

000000000000ad00 T wgsmp1

But when I run the compile, I continue to get errors like this.   And this exact file is the example file that's included with the library.

ifort -L /abs_work/wlib/ -lwsmp64 wgsmp_ex1.f

/tmp/ifortOWJLnd.o: In function `MAIN__':

wgsmp_ex1.f:(.text+0x40): undefined reference to `wsetmaxthrds_'

wgsmp_ex1.f:(.text+0x47): undefined reference to `wsmprtc_'

wgsmp_ex1.f:(.text+0xa4): undefined reference to `wgsmp_'

wgsmp_ex1.f:(.text+0xf0): undefined reference to `wsmprtc_'

wgsmp_ex1.f:(.text+0x12b): undefined reference to `wsmprtc_'

wgsmp_ex1.f:(.text+0x17d): undefined reference to `wgsmp_'

There are more errors, but it does appear to find the library (there's no -lwsmp64 not found error)

Any ideas on what I may be doing wrong ?

[Kevin_D_Intel · Accepted solution]

I just reproduced the same sort of error and found with my case the option order was significant.

Try a different ordering of the command line, like:  ifort wgsmp_ex1.f -L /abs_work/wlib/ -lwsmp64

[TimP]

Put the library reference after the file which has unsatisfied references

[Francis_P_1]

Thank you.   Seems sort of counter-intuitive to me, but it does work.

[mecej4]

Francis P. wrote:

Thank you.   Seems sort of counter-intuitive to me, but it does work.

Intuition is not a good substitute for reading the documentation. A library is not searched if there are no unsatisfied external symbols in the objects that were specified earlier, and libraries are searched in the order in which they are specified. Furthermore, if a library has to be searched more than once, there is a specific ld syntax for specifying that, as you can see with the MKL link line utility. 

[Francis_P_1]

mecej4 wrote:

Quote:

Francis P. wrote:

Thank you.   Seems sort of counter-intuitive to me, but it does work.

Intuition is not a good substitute for reading the documentation. A library is not searched if there are no unsatisfied external symbols in the objects that were specified earlier, and libraries are searched in the order in which they are specified. Furthermore, if a library has to be searched more than once, there is a specific ld syntax for specifying that, as you can see with the MKL link line utility. 

Not going to argue with reading the documentation, but intuition should be considered when designing any application.   And if it's useless to specify the libraries before the source file, perhaps that should cause a syntax error, or perhaps at least a warning.  

I would also say that the documentation could be better written, I've been searching for answers to this for several weeks before coming here, and was not able to find an answer.

[mecej4]

Here are a couple of lines of output from "man ld" for the GNU linker:

The linker will search an archive only once, at the location where it is specified on the command line.  If the archive defines a symbol which was undefined in some object which appeared before the archive on the command line, the linker will include the appropriate file(s) from the  archive.  However, an undefined symbol in an object appearing later on the command line will not cause the linker to search the archive again.

I am sure that the author of ld intended the command and its options to be intuitive, but often one has to read the documentation, at least casually, to be on the same wavelength as the author. I know what my intuition tells me, but divining the intuition of others is not something that I would depend upon. Were intuition to be uniform and infallible, we should have no use for documentation.

[Francis_P_1]

mecej4 wrote:

Here are a couple of lines of output from "man ld" for the GNU linker:

Quote:

The linker will search an archive only once, at the location where it is specified on the command line.  If the archive defines a symbol which was undefined in some object which appeared before the archive on the command line, the linker will include the appropriate file(s) from the  archive.  However, an undefined symbol in an object appearing later on the command line will not cause the linker to search the archive again.

I am sure that the author of ld intended the command and its options to be intuitive, but often one has to read the documentation, at least casually, to be on the same wavelength as the author. I know what my intuition tells me, but divining the intuition of others is not something that I would depend upon. Were intuition to be uniform and infallible, we should have no use for documentation.

Figuring out what makes sense to users is the bane of programmers....

I think any further discussion would take this into basic software design theory.   I don't disagree with you, reading the documentation is important.  But there's always room for improvement in the design too.

[Kevin_D_Intel]

I had remembered the searched only once but not the location on the command line bit. Thanks for the refresher!