Problems with error LNK2001

[Deleted_U_Intel]

I am a beginner user for fortran and has meet up with this problem. It says

dformt.lib(DFORMAIN.OBJ) : error LNK2001: unresolved external symbol _MAIN__
Debug/Hist.exe : fatal error LNK1120: 1 unresolved externals

How do I solve this problem?

I am using CVF 6.1.

I have read the newsletters for MCLS problem but couldn't really solve the problem. Another question is, what is meant but single treaded and multi-treaded. How can I identified this?

Sorry to trouble all the experts here...Many Thanks!!

[Lorri_M_Intel]

This will happen if you don't have a Fortran main program in your project, which is configured to create an executable.

In simpler words :smileywink: Are you creating a console project? If so, is there a main Fortran program? Not to sound too simplistic, but the main program is one which is not a MODULE, SUBROUTINE or FUNCTION, and is where execution is intended to start.

Another possibility is that you are doing mixed-language programming, and the main program is written in C. If that's the case, let us know.

Finally, the last thing to check is whether you actually intended to create a console project, or whether you intended to create a .DLL or .LIB. It's perfectly valid to not have a main program in a library, whether it be static (.LIB) or dynamic (.DLL).

I hope some of this helps -

- Lorri

[g_f_thomas]

I'm getting the same linker error in an IVF (8.1)/VC++ (.NET 2003) DLL soln with a DllMain.c. The error reads:
error LNK2001: unresolved external symbol __uplevel_pack_0

The buildlog also records many:

... : LNK9038: module unsafe for SAFESEH image.

Any hints are welcome,
Gerry T.

[Steven_L_Intel1]

Gerry, yours is a very different error - despite the linker error number being the same. Please send a sample program to Intel Premier Support.

[j_dawg99]

Lorri, I am doing mixed programming with C and Fortran and getting the same error. What is the solution in this case?

Cheers,

-J

[Lorri_M_Intel]

If you're using Intel Visual Fortran, to do mixed language programming you must build a library of Fortran objects and then link against that library in the C/C++ solution where your main program lives. So, make sure that the project you created in the Fortran solution is a library (either static or DLL). If it was a console, then the build would expect to find a Fortran main program.

If you're using Compaq Visual Fortran, you can mix the two languages in the same project, and honestly, I wouldn't have expected this error to happen. My quick experiment showed it didn't, but my really quick and tiny project could be just too tiny.

Does this help?

- Lorri

[j_dawg99]

Thanks, but your postdoesn'treally help... :)

Except that it does confirm I'm going about things the right way (i.e. creating a lib with my fotran objects and trying to link with them). But as soon as Itry to call any fortran routine from the C main, I get the link error.

I should mention I'm using the CVF compiler, but not the studio. I have to compile and link everythingfrom the command line using some funky thrid party scripts(don't ask...), so I figure there is some compiler/linker option that isn't getting turned on.

[Steven_L_Intel1]

Yes - add /nofor_main to the df command that does the linking.

[Lorri_M_Intel]

Ah, command line. Actually, that's good; I'm happy working with commands.

First, it pains me unmercifully to disagree with Steve, but ... the Windows compiler doesn't understand /nofor_main. (Unix only, sorry!)

That aside --- could share enough of the link command so I could get an idea of what's going wrong?

I *just* tried it again, with a C main program and Fortran object, using:

df cmain.obj fsub.obj

and it built just fine. I even tried reversing this, as

df fsub.obj cmain.obj

and it still built OK.

So, I'd be interested in seeing what wasn't working for you.

- Lorri

[Steven_L_Intel1]

Lorri is, as usual, correct - there is no /nofor_main for Windows. There seems to be some "Linux leakage" in my brain today...

[j_dawg99]

Guys,

Yes,a fewcompiler errors and an internet search quickly revealed the /nofor_main option was UNIX only....good try though! :)

I'm linking at the command linewith link.exe. As far I can tell tell, these are theimportant optionsI'm passing to the linker (the scripts I mentioned earlier are a bit difficult to sort out, but I think I got all the options) The only thing I left out are the libs I coded and am using (i.e. the C main, C subroubtines and fortran subroutines)

"/NOLOGO"
"/INCREMENTAL:NO"
"/OUT:ap0c0.exe"
"/nodefaultlib:libc.lib"
"/nodefaultlib:libcd.lib"
"/nodefaultlib:libcmtd.lib"
"/NOLOGO"
"/FORCE:multiple"
"/subsystem:console"
"/PDB:NONE"
"/machine:I386"
"/swaprun:net"
"C:/Program Files/Microsoft Visual Studio/VC98/Lib/KERNEL32.LIB"
"C:/Program Files/Microsoft Visual Studio/VC98/Lib/USER32.LIB"
"C:/Program Files/Microsoft Visual Studio/VC98/Lib/GDI32.LIB"
"C:/Program Files/Microsoft Visual Studio/VC98/Lib/WINSPOOL.LIB"
"C:/Program Files/Microsoft Visual Studio/VC98/Lib/COMDLG32.LIB"
"C:/Program Files/Microsoft Visual Studio/VC98/Lib/ADVAPI32.LIB"
"C:/Program Files/Microsoft Visual Studio/VC98/Lib/SHELL32.LIB"
"C:/Program Files/Microsoft Visual Studio/VC98/Lib/OLE32.LIB"
"C:/Program Files/Microsoft Visual Studio/VC98/Lib/OLEAUT32.LIB"
"C:/Program Files/Microsoft Visual Studio/VC98/Lib/UUID.LIB"
"C:/Program Files/Microsoft Visual Studio/VC98/Lib/ODBC32.LIB"
"C:/Program Files/Microsoft Visual Studio/VC98/Lib/ODBCCP32.LIB"
"C:/Program Files/Microsoft Visual Studio/VC98/Lib/LIBCMT.LIB"
"C:/Program Files/Microsoft Visual Studio/VC98/Lib/MSVCRT.lib"
"C:/Program Files/Microsoft Visual Studio/DF98/Lib/DFORMT.lib"
"C:/Program Files/Microsoft Visual Studio/DF98/Lib/DFQWIN.lib"
"C:/Program Files/Microsoft Visual Studio/DF98/Lib/DFQW_SDI.lib"
"C:/Program Files/Microsoft Visual Studio/DF98/Lib/DFCONSOL.lib"
"C:/Program Files/Microsoft Visual Studio/DF98/Lib/dfport.lib"
"C:/Program Files/Microsoft Visual Studio/VC98/Lib/WINMM.LIB"
"C:/Program Files/Microsoft Visual Studio/VC98/Lib/WS2_32.LIB"
"C:/Program Files/Microsoft Visual Studio/VC98/Lib/IMAGEHLP.LIB"

[j_dawg99]

Small error.

I'm not using

"C:/Program Files/Microsoft Visual Studio/DF98/Lib/DFCONSOL.lib"
"C:/Program Files/Microsoft Visual Studio/DF98/Lib/dfport.lib"

- J

[Lorri_M_Intel]

Okay, thanks ... this is interesting, but I don't have a ready answer yet. (however, I *am* rather stubborn ...)

A few things.

First, let's try looking at a map. Add /map to the link command. Oh, and you might also need to add /force (so that the linker will continue long enough to create a full map)

I predict the map will show that _main (all lowercase) is being resolved in dformt.lib. The trick we need to figure out, is to convince the linker to resolve it in your C main object.

Next, you say you're not linking against dfconsole.lib or dfport.lib ... turns out, you are. There are directives in your Fortran object files to pull in these libraries. If not, you'd have a pile more undefined externals than simply _MAIN__.

Finally, you link list shows 2 C libraries. You only need one. Pick either libcmt or mcvsrt and get rid of the other. I'm sure that's not the cause of this problem, but it is unnecessary. You should probably pick libcmt. Also, I'm not really sure you need both dfqwin and dfqw_sdi, but I need to check on that.

Ah, one more thing. I know you didn't show your files, but where would they be in the list if you had shown them? Like, before the list of libraries? After? Sprinkled through the middle?

thanks -

- Lorri

[j_dawg99]

Hi Lorri,

I can confirm that the main is being resolved in dformt. I actually coded a dummy fortran main program last week to check this. The program linked with and ran the dummy program.

Second, I really don't think I am linking to dfconsole.lib or dfport.lib; I had put them in the linking command as a test, but I have now removed them and I'm still only getting the "__MAIN__" link error.

I do need both dfqwin and dfqw_sdi or else i get undefined externals. However, my feeling is i should not need either of these libs...

Finally, my libraries are included between the /OUT and /NOLOGO options in the linker command i posted earlier.

I thinkthatanswered all of your questions. I eagerly await enlightenment! :)

-J

[Lorri_M_Intel]

BINGO!

Your C main program is in a library, that's what's causing the undefined.

I'm not a linker expert, but let me make a SWAG as to the cause.

There are externals in the Fortran objects that make the linker look in dformt.lib, and once it does, it finds _main and looks no more. Then, because it's resolved _main in the Fortran library, it goes looking for _MAIN__. That's my theory. All the things I'd tried to reproduce your problem didn't put the C main() entry point into a library.

Is it possible to call out the object containing the main() entry point as its own object, rather than putting it into the library? I appreciate that your build procedure is, ah, convoluted. Maybe just before the link step you can do "lib /export:mycmain.obj myclib.lib" and then link it in explicitly.

Let us know, OK?

- Lorri

[j_dawg99]

Well, I finally got around to looking at this again and I think you're right about the linker not liking the main ina lib. I couldn't actually do the test you suggested because I don't have the source for main. Instead Imade a fakemain and linked to that obj instead. Interestingly enough, if I had no fortran in my link, the compiler would complain about main being redefined. But once i added the fortran lib, the warning would disappear. Very strange.

I tried using that /ENTRY:main option in the linker, but this caused other linking problems. Thefix I'm using (suggested by someone a lot more clever than I am) was to make a "MAIN"functionthat calls "main"and use that object in the link:

int MAIN(int argc, char *argv) { main(argc, argv); }

It's a bit sloppy, buteverything seems to work like this.

Thanks for the help. If you have any ideas what could be the root of the problem, I'd appreciate hearing them. I have hade this sort of set-up working in the past without any of these problems...

Cheers,

J-