Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Error linking to external .obj file

Will_M_1
Beginner
858 Views

I have a Fortran DLL project, which requires linking to an .obj file provided by a third party. With it specified in "Additional Dependencies", I get the following errors:

LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
libifcoremd.lib(for_main.obj) : error LNK2019: unresolved external symbol _MAIN__ referenced in function _main

Adding a main function of course solves the compilation error, but I shouldn't need to do that since I'm building a DLL. I'm wondering if there's some project property setting I'm missing, or if this is a problem with the .obj itself.

Fortran and linker command line options:

/nologo /module:"Release\\" /object:"Release\\" /libs:dll /threads /c
/OUT:"Release\TestProj.dll" /NOLOGO /MANIFEST /MANIFESTFILE:"C:\TestProj\TestProj\Release\TestProj.dll.intermediate.manifest" /SUBSYSTEM:WINDOWS /IMPLIB:"C:\TestProj\TestProj\Release\TestProj.lib" /DLL CV580SCAP.obj

I also used dumpbin /directives to check the linker directives of CV580SCAP.obj:

Linker Directives
-----------------
-defaultlib:"IFWIN.LIB"
-defaultlib:"IFWIN.LIB"
-defaultlib:"IFWIN.LIB"
-defaultlib:"IFWIN.LIB"
-defaultlib:"IFWIN.LIB"
-defaultlib:"libifcoremt"
-defaultlib:"libifport"
-defaultlib:"ifqw_sdi"
-defaultlib:"ifqwin"
-defaultlib:"user32"
-defaultlib:"comctl32"
-defaultlib:"gdi32"
-defaultlib:"comdlg32"
-defaultlib:"libmmt"
-defaultlib:"LIBCMT"
-defaultlib:"libirc"
-defaultlib:"svml_dispmt"
-defaultlib:"OLDNAMES"

Using Visual Studio 2008 + Intel Visual Fortran 11.1.3466.2008.

Thanks in advance for any help!

0 Kudos
1 Solution
Steve_Lionel
Honored Contributor III
858 Views

The object you are linking with was built with the option to use the static run-time libraries, whereas your DLL was (properly) built to use the DLL libraries. When you mix these you'll get complaints such as this.

Since Fortran objects don't care which library set is used (this is not true of C/C++), one option could be to set the Linker>Input property "Ignore all default libraries" (/NODEFAULTLIB) in your DLL project. You will then need to name the required libraries under Additional Dependencies. (You can use the dumpbin command on your DLL's object to see a list.)

If you can rebuild the external object, do so with the Fortran > Libraries > Disable default library search rules property set to Yes. Then you should be able to link it in without further issue.

View solution in original post

0 Kudos
2 Replies
Steve_Lionel
Honored Contributor III
859 Views

The object you are linking with was built with the option to use the static run-time libraries, whereas your DLL was (properly) built to use the DLL libraries. When you mix these you'll get complaints such as this.

Since Fortran objects don't care which library set is used (this is not true of C/C++), one option could be to set the Linker>Input property "Ignore all default libraries" (/NODEFAULTLIB) in your DLL project. You will then need to name the required libraries under Additional Dependencies. (You can use the dumpbin command on your DLL's object to see a list.)

If you can rebuild the external object, do so with the Fortran > Libraries > Disable default library search rules property set to Yes. Then you should be able to link it in without further issue.

0 Kudos
Will_M_1
Beginner
858 Views

Thanks for your help, Steve! I was able to get it building using a similar solution, specifically ignoring the static run-time libraries libifcoremt.lib, libifport.lib, libmmt.lib and LIBCMT.lib instead of ignoring all default libraries and specifying only the ones I need.

0 Kudos
Reply