Linker errors

[Bruno_Repetto]

Dear friends:

I have code consisting of a very simple "driver" main program, and a bunch of subroutines. I have no problems compiling, linking and executing this program. What I want to do next is convert just the set of subroutines into a DLL. This is where I get into trouble: it looks as though the linker is linking libraries in the wrong order. Also, there is a reference to a MAIN routine. There is no main program in the DLL project. What is it referring to?? Below is the link log.

Thanks for any help/comments.

Bruno W. Repetto, PhD

1>------ Rebuild All started: Project: MyBusDLL, Configuration: Debug Win32 ------
1>Deleting intermediate files and output files for project 'MyBusDLL', configuration 'Debug|Win32'.
1>Compiling with Intel Visual Fortran Compiler XE 12.0.0.104 [IA-32]...
1>dataproc.for
1>heuristic.for
1>routing.for
1>support.for
1>Linking...
1>LIBCMT.lib(crt0dat.obj) : error LNK2005: __amsg_exit already defined in MSVCRTD.lib(MSVCR90D.dll)
1>LIBCMT.lib(crt0dat.obj) : error LNK2005: __initterm_e already defined in MSVCRTD.lib(MSVCR90D.dll)
1>LIBCMT.lib(crt0init.obj) : error LNK2005: ___xi_a already defined in MSVCRTD.lib(cinitexe.obj)
1>LIBCMT.lib(crt0init.obj) : error LNK2005: ___xi_z already defined in MSVCRTD.lib(cinitexe.obj)
1>LIBCMT.lib(crt0init.obj) : error LNK2005: ___xc_a already defined in MSVCRTD.lib(cinitexe.obj)
1>LIBCMT.lib(crt0init.obj) : error LNK2005: ___xc_z already defined in MSVCRTD.lib(cinitexe.obj)
1>LIBCMT.lib(winxfltr.obj) : error LNK2005: ___CppXcptFilter already defined in MSVCRTD.lib(MSVCR90D.dll)
1>LIBCMT.lib(tidtable.obj) : error LNK2005: __encode_pointer already defined in MSVCRTD.lib(MSVCR90D.dll)
1>LIBCMT.lib(tidtable.obj) : error LNK2005: __encoded_null already defined in MSVCRTD.lib(MSVCR90D.dll)
1>LIBCMT.lib(tidtable.obj) : error LNK2005: __decode_pointer already defined in MSVCRTD.lib(MSVCR90D.dll)
1>LIBCMT.lib(mlock.obj) : error LNK2005: __unlock already defined in MSVCRTD.lib(MSVCR90D.dll)
1>LIBCMT.lib(mlock.obj) : error LNK2005: __lock already defined in MSVCRTD.lib(MSVCR90D.dll)
1> Creating library c:\\Work\\MergeDLL\\MyBusDLL\\MyBusDLL\\Debug\\MyBusDLL.lib and object c:\\Work\\MergeDLL\\MyBusDLL\\MyBusDLL\\Debug\\MyBusDLL.exp
1>LINK : warning LNK4098: defaultlib 'MSVCRTD' conflicts with use of other libs; use /NODEFAULTLIB:library
1>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
1>libifcoremdd.lib(for_main.obj) : error LNK2019: unresolved external symbol _MAIN__ referenced in function _main
1>Debug\\MyBusDLL.dll : fatal error LNK1120: 1 unresolved externals
1>
1>Build log written to "file://c:\\Work\\MergeDLL\\MyBusDLL\\MyBusDLL\\Debug\\BuildLog.htm"
1>MyBusDLL - 14 error(s), 2 warning(s)
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

[mecej4]

The messages are symptomatic of an attempt to link objects some of which were compiled with the /MT option and others that were compiled with the /MDd option.

The fix, if you have the Fortran/C sources for everything, is to clean and rebuild.

If you have only objects for some routines, you can use the /FORCE:multiple linker option as a last resort to try, but that is not recommended since it lets you link potentially incompatible libraries and objects and therefore may produce a malfunctioning EXE file.

[Bruno_Repetto]

I have source code for what I wrote, and I have to link with two separate libraries (.lib) for which I do not have source code. How would I use the /FORCE command in this case?

Also, why would the link step fail when creating the DLL, while the link step completed successfully (and a good executable was generated) in the instance when I created the executable version? (And I didn't need a /FORCE command in the link step of the executable version.)

Thanks,

Bruno

[Bruno_Repetto]

I'd like to close this thread.

I discovered what I was doing wrong. It had nothing to do with conflicting libraries or such, but rather that I had more code than what I needed to generate my DLL. Not sure why, but removing the extra code successfully produced a nice and usable DLL, with no warning messages at the link step.

Thanks to all who responded.

Bruno