none
Linking with c .lib

    Question

  • By using VC++ 6.0 console application project, it works to link my c .lib library.
    But when using VC++ 6.0 Win32 DLL project, it throws "omnt.lib(OAPISOC.OBJ) : error LNK2001: unresolved external symbol _errno".

    Anyone can help please? Thank you.
    Friday, September 01, 2006 4:06 AM

Answers

  • Angus said
    "Actually the development is supposed to be developing on C++.NET platform"

    But you said you were using VC6!!!! Are you trying to use a VC6 lib in a different compiler? If yes, then you should recompile your lib in the same version as the program that uses it. Please give us details of what compiler(s) you are using so we can zero down on the problem.


    The last time I had the same problem; it was resolved when the dependent .lib was compiled with the same switch as the DLL. For example /MD and the /ML compiler switches are the most common once to cause that kind of an error while making the DLL, while the console app using the same lib works just fine.

    Friday, September 01, 2006 8:54 AM

All replies

  • Have you made sure that the compiler switches are the same for the executable and the DLL? The IDE generates different default compiler switches for console app and DLL. This may be causing the problem.
    Friday, September 01, 2006 4:30 AM
  • Thank you for your reply.

    I found that the two compiler switches are almost the same and I don't see any critical difference would cause the problem.

    Actually the development is supposed to be developing on C++.NET platform, but it throws the same error.
    Friday, September 01, 2006 7:09 AM
  • Angus said
    "Actually the development is supposed to be developing on C++.NET platform"

    But you said you were using VC6!!!! Are you trying to use a VC6 lib in a different compiler? If yes, then you should recompile your lib in the same version as the program that uses it. Please give us details of what compiler(s) you are using so we can zero down on the problem.


    The last time I had the same problem; it was resolved when the dependent .lib was compiled with the same switch as the DLL. For example /MD and the /ML compiler switches are the most common once to cause that kind of an error while making the DLL, while the console app using the same lib works just fine.

    Friday, September 01, 2006 8:54 AM