Linking Fortran libs with C++ code...

[munchymonster]

We've been using IVF9.0 and VS.NET2003 to work a project with mixed C++ and Frotran libraries for some time now. After a few bumps early on things had been going quite smoothly. We now need to take one of the libraries that we hav created (mixed C++ and Fortran bits in it) and share it with another group. This other group does not have access to IVF. We want to just supply them with a static lib and a list of C++ header files. Our C++ code calls our Fortran code and the other group doesn't even need to know that there is Fortran "under the hood". We compile the C++ static lib and use Properties->Librarian->General->Additional Dependencies to "include" the Fortran lib. The other group tried using this and got link errors pointing to some of the standard Fortran libs (ifconsol.lib, etc.). So we added those libs to the additional dependencies and tweaked the Properties->Fortran->Libraries->Disable Default Library Search Rules to YES so we would look in our static lib instead of looking in some default location. That got us past most of the link errors we had been seeing, but nowthe other group isgetting "LINK : fatal error LNK1104: cannot open file 'libirc.lib' "

Any Ideas how we get around this?

-MunchyMonster

[Steven_L_Intel1 · Accepted solution]

What you did by changing the default library search rules setting was to require the builder of the executable to specify which Fortran libraries were to be used. This does not remove the dependency on the libraries.

You are allowed to copy libirc.lib along with your static library. Another option would be to build your library as statically-linked DLL which would resolve all outside references. You'd then need to provide your DLL and the export library created when you build the DLL (and don't forget to DLLEXPORT the routines you want exported.)

Steve

[munchymonster]

Quoting - Steve Lionel (Intel)

You are allowed to copy libirc.lib along with your static library. Another option would be to build your library as statically-linked DLL which would resolve all outside references. You'd then need to provide your DLL and the export library created when you build the DLL (and don't forget to DLLEXPORT the routines you want exported.)

Steve

So just to make sure I've got this right.

The consumer of my library doesn't need to know and doesn't want to know how we get things done. They want to link to our lib statically and have everything they need (no unresolved symbols and no missing libs).

If I create a statically linked DLL, it will resolve all of the outside references at link time for the stically linked DLL. I then distribute the DLL and the LIB to my consumer and they use it as they have been our static lib. Since all the external references to the Fortran libs was resolved by statically linking the DLL they won't need any of that stuff and (assuming I've done my job right) everything will just work.

This is a stupid question, but will they require the statically linked DLL at runtime or is that the point behind making it a statically linked DLL? I figured we might need to go down this path, but I was hoping I could push it off to our next release.

Thanks,

MunchyMonster

[Steven_L_Intel1]

The user of the statically-linked DLL will need your DLL to be available - either in PATH or in the folder containing the EXE. But because it is statically linked, they will not need any of the Intel or Microsoft libraries or DLLs along with it.

[munchymonster]

Quoting - Steve Lionel (Intel)

The user of the statically-linked DLL will need your DLL to be available - either in PATH or in the folder containing the EXE. But because it is statically linked, they will not need any of the Intel or Microsoft libraries or DLLs along with it.

Thanks! That is what I expected, butI wanted to make sure.

-MunchyMonster