Creating a DLL: dependency on libifcoremdd.dll and a missing symbol _MAIN__

[Arjen_Markus]

Hello,

I am trying tocreate a DLL out of one of our programs and at link time I get a
message about libifcoremdd.dll missing a symbol _MAIN__:

libifcoremdd.lib(for_main.obj) : error LNK2019: unresolved external symbol _MAIN__ referenced in function _main

I have not been able to reproduce this ina smallerlibrary and I have no clue where the dependency
is coming from. My question, of course, is: how do I get rid of this message?

Right now, I use the/force option to the linker, as thereare also numerous doubly-defined symbols,
but if I use the DLL I get in the program that should use it,that program crashes at start-up - most probably
this missing symbol.

I hope this is enough information to get started with analysing the problem, as the project is rather large.

Regards,

Arjen

[mecej4]

If you can show the link-step command line, that would help in finding out what the crux of the problem is. Are you using a module definition file (.DEF) to build the DLL?

The message about the missing _MAIN__ suggests that the linker is being called by the IFort compiler, and that it seems to think that an .EXE file has been requested rather than a DLL. The solution for that is to use the compiler switch /LD, or the linker switch /DLL.

[Arjen_Markus]

No, I use compiler directives to export the various routines. The command-line does contain the option /DLL - it is all done via Visual Studio 2008. I do see an oddity: the option /nodefaultlib does not split the list of libraries. I will check that.

Regards,

Arjen

[Arjen_Markus]

Yes! That did the trick: I had "libc.lib libcmtd.lib msvcrtd.lib" as the value for "Ignore Specific Libraries", instead of "libc.lib, libcmtd.lib, msvcrtd.lib". If you leave out the commas, the whole string is regarded to be
a single name. The command-line showed that interpretation.

(The formatting of this option is different from the first onejust above it: for "Additional Dependencies" you do not need to insert commas between the names. There has got to be a good reason for it, but I am not
sure I like this type of seemingly arbitrary differences - just a long-standing grudge)

mecej4, thanks for pointing me to the command-line proper.

Regards,

Arjen

[Jugoslav_Dujic]

...however, Arjen, /IGNORE: is almost always the wrong cure, as it may lead to other problems. The source of the problem is mismatch in used run-time libraries in components that you used to assemble the .dll. You should make sure that your C++ and Fortran settings in all used components have the same setting (C++/Code Generation/Runtime library and Fortran/Libraries/Runtime library).

For static libraries, I also recommend setting C++/Advanced/Libraries/Omit Default Library Names and Fortran/Libraries/Disable default Library Search Rules to "Yes" (/libdir:noauto). That basically says "don't embed information about RTL in the .lib; the final .exe/.dll will determine it". That reduces the possibility of the infamous "Multiple C library syndrome". However, if your final .exe/.dll is C++, you will have to explicitly spell your Fortran RTLs in the linker command line.

[Steven_L_Intel1]

Did your program contain any QuickWin calls? If so, it cannot be made into a DLL and would trigger a reference to _MAIN__.

I agree with Jugoslav that /IGNORE should be a last resort.

What is the value for the linker property Subsystem?

[Arjen_Markus]

Hi Jugoslav, Steve,

I added the /force option because in the past I have noticed (but may have been wrong about the commas then too) that it was the only way to get the linker to do the job. If my memory serves me,one such occasionhad to do - among other things - with errno in a C program: this came in apparently from different libraries and no combination of ignored system libraries that I tried solved it.

Theprogram contains no QuickWin callswhatsoever.

I will see what happens without the /force option, but I can not control all the components that go into the DLL - some are external third-party libraries.

Regards,

Arjen

[Arjen_Markus]

Leaving out /force was successful: at least the DLL is built without any warnings or errors.

Regards,

Arjen

[Jugoslav_Dujic]

Quoting arjenmarkus

I can not control all the components that go into the DLL - some are external third-party libraries.

Yes, that's what I was afraid of. If they were built with /libdir:noauto (/Zl), you probably wouldn't have those conflicts. You can find out which libraries they pull by using

dumpbin /directives foo.lib

but I don't know of a way to strip them off, other than specifying /IGNORE or, better, /NODEFAULTLIB.

This thread has some useful stuff, though no particular cure. If you receive a badly compiled third-party library, you're probably stuck with adding linker switches.

You did not specify if it is all Fortran or there is some C++ code as well. To add salt to the wound, VC++ compiler in some cases emits different code with different RTL settings, so that even if you use /Zl there's no 100% guarantee that the .lib will play nice with code (of a different RTL setting) that uses it. Intel Fortran does not do that.

[Arjen_Markus]

Not to mention the various versions of MSVCR90.DLL and friends :(. I ran into a problem with that particular libary a while back - two libraries in a program requiring different versions, but one was lying about the version it wanted via the manifest file. The only way I could solve itwas by recompiling one of them.

I still do not completely understand how the problem arose, but I am gladwe found a cure.

My program is mainly Fortran, but it does have some Cmixed in (as well as OpenMP and MPI for
goodmeasure :)).

Regards,

Arjen