Error lnk2019: unresolved external symbol when Compiling ARPACK package

Error lnk2019: unresolved external symbol when Compiling ARPACK package

Hello,

I am trying to compile one of the fortran files (sssimp.f) in arpack examples directory in intel visual fortran compiler. It has external dependencies of arpack_win32,blas_win32 andlapack_win32.

This is a screenshot of my setup, and the error I got:

Is there any reason why I got this error, even though I have all the dependencies included in the vfproj file?

For your reference, as you can see, I set the additional dependencies for all the relevant *.lib file in my property page, as shown:

17 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

This is the content of my vfproj file:

<?xml version="1.0" encoding="UTF-8"?>

<?xml version="1.0" encoding="UTF-8"?>

The respective dlls can be found at:

http://www.stanford.edu/~vkl/code/libs.html

As you don't care to understand MingW calling conventions, and would run into Fortran run-time library conflicts, it would be much easier to use the source code, or the MKL versions of the same functions which come with ifort.

If you were serious about using these libraries, it would be advisable to study iso_c_binding.

The URL you gave indicates clearly that the libraries were built with a several year old version of MingW. Beyond that, it's extremely short on compatibility information; it probably didn't even include gfortran. It seems to be based on the assumption that no one would ever use a different compiler, nor even upgrade to current versions.

it would be much easier to use the source code, or the MKL versions of the same functions which come with ifort.

I would use MKL versions for the same functions if only MKL supports ARPACK ( it doesn't).

Is there a suggestion that you can put forth to me so that I know how to modify the sssimp.f file, so that it can compile in intel fortran without modifying and recompiling all the larpack_win32, arpack_win32 and blas_win32?

How did the person who posted those libraries compile it? It appears they would be obligated to post source code or at least patch diffs from a reliable reference version.

Haven't the problems associated with proprietary extensions in the Fortran ARPACK been dealt with before? e.g.

http://people.sc.fsu.edu/~burkardt/f_src/arpack/arpack.html

As mentioned, the source code is already there (sssimp.f). So, my question is that I want to take the existing arpack_win32, blas_win32, and lapack_win32.dll, and try to compile sssimp.f against them. That means the most I do is modify sssimp.f and nothing more.

Is it possible?

I'm unable to unpack the .7z file with the libraries - 7Zip gives me "invalid command line". I will comment that we don't support linking to gcc-generated objects and libraries. It's likely that the library is not in a format understood by the Microsoft linker.

Can you attach the .dll and .lib you are using?

Retired 12/31/2016

All the related blas_win32, lapack_win32 and arpack_win32 are available here.

I will attach a copy of those dlls, just in case you can't get from the above address. But wait until I get to the office ( I'm in Malaysia)

An additional question, since you say that you don't support "linking to gcc-generated objects", does this mean that I have to recompile ARPACK myself in visual fortran, link it to MKL version of LAPACK and BLAS, and compile the wrapper I write around ARPACK ( I'll be using pardiso solver for matrix solving functions)?

That would be awefully lots of work.

It would be more work, with less probability of success, to try to find a way to link to objects built with an obsolete version of gcc/g77 with no intention of compatibility with VS.

I saw you linked to that page, but none of the download .7z files open for me.

I suggest you take Tim's advice - it is unlikely that those g77 libraries will be usable for you.

Retired 12/31/2016

Here is the related blas_win32, arpack_win32 and lapack_win32.

I don't quite understand your point; are you saying that the dlls compiled in older version of gcc cannot be used to link to visual fortran compilation? In other words, the above dlls ( products of gcc compilation) cannot be made work with sssimp.f compilation in visual fortran?

Attachments: 

AttachmentSize
Downloadapplication/zip ARPACK.zip5.94 MB
Best Reply

Intel Visual Fortran does not support use of objects and libraries compiled with gcc. That is not to say that it won't work - it might.

Looking at the DLLs you attached, I see that all the routine names are in lowercase and have a trailing underscore. This is a Linux/UNIX convention. You can try to make it work by adding the options:

/iface:cref /assume:underscore

to the ifort compiles. I generally advise against using such options, but it may be a quick and dirty way to get this combination to build.

Retired 12/31/2016

Thanks, your solution works.

But, why you advise against such hacks? Is there any specific reason other than "it's not supposed to work because it is not officially supported"?

I have experimented with a similar combination and it worked for me too. However, I can imagine a few

things that will not work, as they rely on cooperation between the respective run-time libraries:

- Allocatable arrays that are allocated by code fromone compiler and deallocated by code from the other

- Pointer variables (similar situation)

- Writing to files that were opened by code from the other compiler

- Passing assumed-shape arrays

- Optional arguments

In short: much that was new in Fortran 90 and then some.

If the routines are not using these features though, then chances are good it works.

Regards,

Arjen

My preference is to use the language's C interoperability features (BIND(C), primarily), to adjust naming conventions. I dislike use of "big hammer" command line switches that globally change naming and calling conventions because sometimes they affect things you don't want changed. This has nothing to do with the use of gcc-compiled objects.

Retired 12/31/2016

Leave a Comment

Please sign in to add a comment. Not a member? Join today