error LNK2001: unresolved external symbol _errno

[Thomas3]

I use IVF 10.1.029 Prof w/ VS2008 Pro.

I try to rebuild a sample fortran program which was built successfully under IVF 9.x with VS2003 Pro.

I regenerate a new console fortran project and then input the necessary options as I did in my old development environment. However I get link error messages as follows:

Error1 error LNK2005: __cinit already defined in LIBCMTD.lib(crt0dat.obj)LIBC.lib
Error2 error LNK2005: _exit already defined in LIBCMTD.lib(crt0dat.obj)LIBC.lib
Error3 error LNK2005: __exit already defined in LIBCMTD.lib(crt0dat.obj)LIBC.lib
Error4 error LNK2005: __cexit already defined in LIBCMTD.lib(crt0dat.obj)LIBC.lib
Error5 error LNK2005: __c_exit already defined in LIBCMTD.lib(crt0dat.obj)LIBC.lib
Error6 error LNK2005: __C_Exit_Done already defined in LIBCMTD.lib(crt0dat.obj)LIBC.lib
Error7 error LNK2005: __C_Termination_Done already defined in LIBCMTD.lib(crt0dat.obj)LIBC.lib
Error8 error LNK2005: __exitflag already defined in LIBCMTD.lib(crt0dat.obj)LIBC.lib
Error9 error LNK2005: __wpgmptr already defined in LIBCMTD.lib(crt0dat.obj)LIBC.lib
Error10 error LNK2005: __pgmptr already defined in LIBCMTD.lib(crt0dat.obj)LIBC.lib
Error11 error LNK2005: ___winitenv already defined in LIBCMTD.lib(crt0dat.obj)LIBC.lib
Error12 error LNK2005: __wenviron already defined in LIBCMTD.lib(crt0dat.obj)LIBC.lib
Error13 error LNK2005: ___initenv already defined in LIBCMTD.lib(crt0dat.obj)LIBC.lib
Error14 error LNK2005: __environ already defined in LIBCMTD.lib(crt0dat.obj)LIBC.lib
Error15 error LNK2005: ___wargv already defined in LIBCMTD.lib(crt0dat.obj)LIBC.lib
Error16 error LNK2005: ___argv already defined in LIBCMTD.lib(crt0dat.obj)LIBC.lib
Error17 error LNK2005: ___argc already defined in LIBCMTD.lib(crt0dat.obj)LIBC.lib
Error18 error LNK2005: __umaskval already defined in LIBCMTD.lib(crt0dat.obj)LIBC.lib
Error19 error LNK2005: ___lookuptable already defined in LIBCMTD.lib(output.obj)LIBC.lib
Error20 error LNK2005: ___wnullstring already defined in LIBCMTD.lib(output.obj)LIBC.lib
Error21 error LNK2005: ___nullstring already defined in LIBCMTD.lib(output.obj)LIBC.lib
Warning22 warning LNK4098: defaultlib 'LIBC' conflicts with use of other libs; use /NODEFAULTLIB:libraryLINK
Error23 fatal error LNK1169: one or more multiply defined symbols foundDebug\IndSamp1.exe

So I ignoew libc.lib by filling the "libc.lib" on "Ignore Specific Library" option. Then I still got error messages as follows:

Error1 error LNK2019: unresolved external symbol _errno referenced in function _crsp_errprintfcrsp_lib.lib
Error2 error LNK2001: unresolved external symbol _errnocrsp_lib.lib
Error3 error LNK2001: unresolved external symbol _errnocrsp_lib.lib
Error4 fatal error LNK1120: 1 unresolved externalsDebug\IndSamp1.exe

How could I solve this problem?

Thanks.

Thomas

PS: In my PC I also installed VS 6.0. Will this effect the linking operation?

[Steven_L_Intel1]

Do not use "ignore library". Remove any references to libc.lib you may have had, make sure the Run-Time Library is set to Multithreaded and Rebuild the solution (don't just do a build.) My guess is that you still have objects built with 9.1 that refer to libc. You will also need to rebuild your .lib.

Installing VS 6 won't have any effect.

[Thomas3]

Quoting - Steve Lionel (Intel)

Do not use "ignore library". Remove any references to libc.lib you may have had, make sure the Run-Time Library is set to Multithreaded and Rebuild the solution (don't just do a build.) My guess is that you still have objects built with 9.1 that refer to libc. You will also need to rebuild your .lib.

Installing VS 6 won't have any effect.

Steve,

Thank you for your help.

In fact, what I did was
1. re-create a empty Fortran "Console Application"
2. add "Existing item" (the indsamp1.f90)
3. add the "crsp_lib.lib" in "Additional Dependencies"
4. Add necessary include and lib paths.
There is no reference and option use libc.lib. The "Runtime Library" also set to "Debug Multithreaded (/libs:static /threads /dbglibs)".

Your answer gave me some idea. I searched the content of crsp_lib.lib and found there is some ASCII code and transferto letters are '/DEFAULTLIB:"LIBC"'. Look like the crsp_lib.lib somehow reference Libc.lib and I cannot change it. Is there a option to solve it.

Thank you for your answer.

Thomas

[Steven_L_Intel1]

If this is C code, then your only option, I think, is to get it rebuilt using a newer MSVC compiler. You can try the /IGNORELIB:LIBC.LIB but it may give link errors. The C compiler generates different code for single vs. multithread libraries.

[Thomas3]

Quoting - Steve Lionel (Intel)

If this is C code, then your only option, I think, is to get it rebuilt using a newer MSVC compiler. You can try the /IGNORELIB:LIBC.LIB but it may give link errors. The C compiler generates different code for single vs. multithread libraries.

Steve,

What I have is a 3rd-party library file without source code. So I cannot rebuild it unfortunately. I've re-installed my VS2003 and IVF v9.1. Then all errors were gone.It seems like that I still need to keepmultiple version VS in my PC.

But this make me think of one situation. If I get a 3rd-party library (static or dynamic), and it was build by OLD version compiler as a single-threaded program (just like my case), even I ignoew LIBC.LIB I may still get "error LNK2001: unresolved external symbol xxxxx". Is there a solution. Any suggestion?

Thank you.

Thomas

[Jugoslav_Dujic]

Quoting - Thomas

Steve,

What I have is a 3rd-party library file without source code. So I cannot rebuild it unfortunately. I've re-installed my VS2003 and IVF v9.1. Then all errors were gone.It seems like that I still need to keepmultiple version VS in my PC.

Object code generated by Ifort and C compilers may have "OBJCOMMENTs", i.e. "directives" or "hyperlinks" which [run-time] library to use. That's generally fine for .exes or .dlls, but the problem comes with static libraries -- when you link the .exe with a library other than the one of the .lib, you get the LNK errors.

You can examine their existence (libc.lib) by typing

dumpbin /directives the3rdparty.lib

To disable those objcomments, appropriate compiler option (/libdir:noauto IIRC) should have been selected. That option is the default for static library projects (created from IDE) in Ifort, but was the default in CVF. The library authors didn't seem to know about that.

Unfortunately, you seem to be stuck with having the old version installed. I don't know of a way to remove those directives. (Although maybe some "creative" use of hex editor + an amount of praying might help to replace those /DEFAULTLIB:LIBC...).

Which unresolved symbols you get after /IGNORELIB?

[Steven_L_Intel1]

It's easy to prevent the DEFAULTLIB:'libc.lib' from being used - /IGNORELIB will do that. The real problem is that the C++ compiler generates different and incompatible code for references to C library globals such as errno when you change from single-threaded to multithreaded. I'll comment that C-only users would have the same problem with this library - are you sure it hasn't been updated in the past three years?

[Thomas3]

Quoting - Jugoslav Dujic

Object code generated by Ifort and C compilers may have "OBJCOMMENTs", i.e. "directives" or "hyperlinks" which [run-time] library to use. That's generally fine for .exes or .dlls, but the problem comes with static libraries -- when you link the .exe with a library other than the one of the .lib, you get the LNK errors.

You can examine their existence (libc.lib) by typing

dumpbin /directives the3rdparty.lib

To disable those objcomments, appropriate compiler option (/libdir:noauto IIRC) should have been selected. That option is the default for static library projects (created from IDE) in Ifort, but was the default in CVF. The library authors didn't seem to know about that.

Unfortunately, you seem to be stuck with having the old version installed. I don't know of a way to remove those directives. (Although maybe some "creative" use of hex editor + an amount of praying might help to replace those /DEFAULTLIB:LIBC...).

Which unresolved symbols you get after /IGNORELIB?

Jugoslav,

Thank you for your suggestion. I'll try those options some other day.

About the error messages afterignoring:LIBC.LIB, please refer to my original submission. In it there are 2 sets of error messages. The 2nd part is the link error messages after I ignoring LIBC.

Thomas

[Thomas3]

Quoting - Steve Lionel (Intel)

It's easy to prevent the DEFAULTLIB:'libc.lib' from being used - /IGNORELIB will do that. The real problem is that the C++ compiler generates different and incompatible code for references to C library globals such as errno when you change from single-threaded to multithreaded. I'll comment that C-only users would have the same problem with this library - are you sure it hasn't been updated in the past three years?

I checked the options in VS2003, VS2005, and VS2008. The VS2003 still supports "Single Thread" and that's why I could build my project without an error.

Like you said, I could ignore LIBC but got more tedious errors. I notice the new version software has been issued which supports VS2005. I did not have it yet. But I found the "Setup Note" from google and it suggested use option "/nodefaultlib:libcmt". I guess the new version might fix the issue and will not have error messages I got.

[Jugoslav_Dujic]

Quoting - Thomas

I checked the options in VS2003, VS2005, and VS2008. The VS2003 still supports "Single Thread" and that's why I could build my project without an error.

Like you said, I could ignore LIBC but got more tedious errors. I notice the new version software has been issued which supports VS2005. I did not have it yet. But I found the "Setup Note" from google and it suggested use option "/nodefaultlib:libcmt". I guess the new version might fix the issue and will not have error messages I got.

Just tell them -- if you can -- to use /libdir:noauto, or, if it's written in C/C++ /Zl (http://msdn.microsoft.com/en-us/library/f1tbxcxh(VS.80).aspx)... That allows the using project to supply whatever RTL is suitable for its own needs.

As Steve pointed out, the root of the problem is that C++ compiler actually does emit different code for different selected RTL. I'm positive that /libdir:noauto works well for Fortran, but /Zl in C++ might have some side effects. You'll have to check a VC++ forum for that though.

[Steven_L_Intel1 · Accepted solution]

/Zl suppresses the object directives to pull in libraries, but for C++, does NOT change how code is generated. So it won't help with unresolved references.