creating a static library

[John_S_16]

I have just upgraded my fortran IDE to the INTEL Parallel Studio XE Composer Edition for Fortran Windows. I am currently having difficulty creating a new static library of subroutines that I have developed over the years. The existing static library, which I made using my previous version of visual studio, works fine. But when I create a new version of this library, I get the error messages shown in the attached.

[mecej4]

The error messages in your attachment pertain to linking, not creating the library. From those messages, I cannot discern whether your library was created, whether it was used by the linker, nor can I see any of the commands used to do the linking.

We need more details before we can provide any answers.

[Steve_Lionel]

If you're creating a static library, the linker should not be involved at all. I suggest creating a new project and making sure you specify that it is a static library project.

[John_S_16]

Steve,

I have recreated the library that works twice, once using the VS 2015 platform and once from the command line. In both cases, the object files are generated and assembled into a libx.lib file. In all cases, whether using the lib file that does work or the newly created ones, the libraries are attached using the Resource folder found in the Solution Explorer window. Neither of the new versions work and I get the errors shown in the previous attachments. Building the solution files with the older previously developed lib file goes without a hitch and the  program works fine.

Your thoughts

[Steve_Lionel]

So you're saying now that it's not the creation of the library but rather the linking of an executable using that library? There's a lot you have not told us so far - please attach a ZIP containing the buildlog.htm of all the projects involved along with the .vfproj files of those projects.

[mecej4]

If you will attach the two versions of the library zipped together, those would provide useful information and may lead to a resolution of the issue.

[IanH]

In all cases, whether using the lib file that does work or the newly created ones, the libraries are attached using the Resource folder found in the Solution Explorer window.

That reads as if you are putting the library files under the "Resource Files" folder for your Fortran project.  If so, I have no idea whether that will work or not, but library files are very typically not considered resource files.  Resource files define things like icons, menus, and dialog boxes.

[John_S_16]

Steve,

My issue is that any newly created libraries (*.lib) simply do not work despite their apparent successful creation. What does work is an older library file. left over from my VS 2005 days, i.e. lib2.lib. As per your request, I am attaching a files that you wanted to see. In order to send the  library files, *.lib, I changed their extensions.

Thank you.

John

[Steve_Lionel]

Thanks for the information - it helps.

You have what we in the business refer to as "Mixed C Library Syndrome". Intel developer Lorri Menard first wrote about this back when she (and I) worked for Digital, but I see I didn't include it in the DVF Newsletter archive in this forum. But you also have an additional complication, that being "Mixed Fortran Library Syndrome", which can be worse.

Your executable program Tstat asks to link to the QuickWin libraries.  This requires linking to the static form of the Fortran run-time libraries. But your static libraries are built using a default setting to link to the DLL libraries, both Fortran and MSVC, and this results in multiple copies of libraries being pulled in resulting in errors.

The reason your old library works is that it is from a time when the default, in both Fortran and MSVC, was to link to static libraries. Here's the linker directives from your old library:

   -defaultlib:ifconsol
   -defaultlib:libifcoremt
   -defaultlib:libifport
   -defaultlib:libmmt
   -defaultlib:LIBCMTD
   -defaultlib:libirc
   -defaultlib:svml_disp
   -defaultlib:OLDNAMES

and here's the new:

   -defaultlib:ifconsol
   -defaultlib:libifcoremdd
   -defaultlib:libifportmd
   -defaultlib:libmmdd
   -defaultlib:MSVCRTD
   -defaultlib:libirc
   -defaultlib:svml_dispmd
   -defaultlib:OLDNAMES

Try this - in your library project, set the property "Fortran > Libraries > Disable Default Library Search Rules" to Yes, and rebuild. This tells the compiler to not put any library directives in the library objects - for static libraries this is usually the best choice, as it then uses whatever the executable project asks for. You might not want to do this if the executable project is not Fortran, but even then you have to make sure that the C libraries match between executable and library.

[mecej4]

Steve has shown you the way to resolving the linking problem; here are a couple of comments regarding the two libraries that you attached.

Both libraries contain equt.obj, which was derived from a program rather than a subprogram. There is little reason to include a main program in a library.

Using Ifort 18.0.2, I attempted to link the extracted equt.obj with the other .LIB file, i.e., (i) linking lib2_old.lib and the equt.obj from my_lib.lib and (ii) vice versa. In both cases, I saw linker errors of the same type as what you saw.

Next, I did straight linking, i.e, (i) my_lib.lib with the equt.obj from that lib, and (ii) lib2_old.lib with the equt.obj from that lib. In both cases, the EXE was built and seemed normal when I ran it.

I do not have the version 10 compiler on the computer where I did my tests. You would probably encounter the same issues if you built the two libraries today with the 18.0.2 compiler but with their different (static versus dynamic) RTL dependencies as specified in the two project settings.

Also, as noted in the earlier responses, there were absolutely no problems related to creating the library.

[John_S_16]

Steve and mecej4:

Thank you for your help on my library problem. Success!!!

I made the changes that Steve recommended and can now successfully build static libraries without the linking error issues discussed above. Also, I appreciate the comment about finding a program file, i.e. not a subroutine file, in my library. I simply did not notice that. However, even when I remove that EQUT.for program from the library source code set and rebuild, I still get the errors discussed above.

John

[Steve_Lionel]

The main program object would not have been pulled from the library since there was already a main program seen by the linker. I think mecej4 mentioned that just because it was spurious, not because removing it would change the behavior.