none
VS 2005 linker error? Unresolved __imp__stat

    Question

  • Hello,

     

    I have a couple of different applications (for x86) that I'm attempting to
    build under Visual Studio 2005 that each encounter the following problem.

     

    The source files all compile. When they attempt to link, it gives
    a link error about the unresolved symbol __imp__stat. It lists it
    once from each of two files in a library we use (third party), and
    also from OLDNAMES, which is strange, since I might expect the contents
    of that library to be resolving this external.

     

    The funny thing is, this fails only 80-90% of the time. If I keep telling it
    to build, over and over, every so often it will succeed, without my changing
    anything!

     

    We link with a bunch of our own libraries, plus the following MS libraries
    that are either from VS 2005 or from the Windows 2008 DDK.

     

    comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib
    comctl32.lib rpcrt4.lib wsock32.lib Iphlpapi.lib setupapi.lib newdev.lib
    Shlwapi.lib

     

    The following is a build log from the error.

     

    Note that the names have been changed to protect the innocent. Also, there are
    actually more like 30 source files involved, not that it's likely to matter.

     

    1>------ Build started: Project: abcd, Configuration: Release Win32 ------
    1>Compiling...
    1>abcd1.cpp
    1>abcd2.cpp
    1>Generating Code...
    1>Compiling resources...
    1>Linking...
    1>abcd21.lib(abcd31.obj) : error LNK2019: unresolved external symbol __imp__stat referenced in function _jIZlHvZLZ
    1>abcd21.lib(abcd32.obj) : error LNK2001: unresolved external symbol __imp__stat
    1>OLDNAMES.lib(stat.obi) : error LNK2001: unresolved external symbol __imp__stat
    1>..\windows\bin.2005\configtool.exe : fatal error LNK1120: 1 unresolved externals
    1>Build log was saved at "file://c:\abcd\BuildLog.htm"
    1>abcd - 4 error(s), 0 warning(s)
    ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

     

    I'm guessing this is some sort of linker bug, but I'm open to suggestions as
    to how to proceed.

     

                            Thanks,
                            Nathan

    Wednesday, April 09, 2008 7:30 PM

Answers

  • >abcd21.lib(abcd31.obj) : error LNK2019: unresolved external symbol __imp__stat referenced in function _jIZlHvZLZ

     

    Do you have the source for abcd21.lib or is this one of the third party libraries? If you have the source, can you find the _jIZlHvZLZ function and see what it refers to?

     

    Remember that libraries are sometimes dependent on the compiler version. Did you already check with your vendor to ensure it is compatible with VS2005?


     

     

    Wednesday, April 09, 2008 11:32 PM
  • Hi,

     

    It is strange that sometime VC++ will build it with no errors.

     

    And I think the cause is obvious, the compiler can’t find symbols of specific imported functions in the third-party import libraries, and I think you’d better consult the third-party library provider for this issue.

     

    Thanks!

     

    Tuesday, April 15, 2008 11:27 AM

All replies

  • >abcd21.lib(abcd31.obj) : error LNK2019: unresolved external symbol __imp__stat referenced in function _jIZlHvZLZ

     

    Do you have the source for abcd21.lib or is this one of the third party libraries? If you have the source, can you find the _jIZlHvZLZ function and see what it refers to?

     

    Remember that libraries are sometimes dependent on the compiler version. Did you already check with your vendor to ensure it is compatible with VS2005?


     

     

    Wednesday, April 09, 2008 11:32 PM
  • Thanks for replying.

     

    >>abcd21.lib(abcd31.obj) : error LNK2019: unresolved external symbol
    >>__imp__stat referenced in function _jIZlHvZLZ
    >
    >Do you have the source for abcd21.lib or is this one of the third party
    >libraries? If you have the source, can you find the _jIZlHvZLZ function and
    >see what it refers to?

     

    No; it is one of the third party libraries, and we have no sources.

     

    Note that the second instance of the message does not mention a function
    name.

     

    >Remember that libraries are sometimes dependent on the compiler version. Did
    >you already check with your vendor to ensure it is compatible with VS2005?

     

    We didn't check for compatibility. I'm pretty sure it was compiled with either
    VS .NET 2003 or maybe VC 6.0.

     

    However, as far as compatibility goes, if it were incompatible, how come
    sometimes the link succeeds with no errors?

     

    Also, looking at what the error actually says, about __imp__stat, shouldn't
    that be resolved by OLDNAMES?

     

                            Thanks,
                            Nathan

    Thursday, April 10, 2008 2:41 PM
  • Hi,

     

    It is strange that sometime VC++ will build it with no errors.

     

    And I think the cause is obvious, the compiler can’t find symbols of specific imported functions in the third-party import libraries, and I think you’d better consult the third-party library provider for this issue.

     

    Thanks!

     

    Tuesday, April 15, 2008 11:27 AM
  • >>It is strange that sometimes VC++ will build it with no errors.
    >
    >And I think the cause is obvious, the compiler can’t find symbols of specific
    >imported functions in the third-party import libraries, and I think you’d
    >better consult the third-party library provider for this issue.

     

    The function it cannot find is the import symbol for the standard
    CRT function stat. It is not a symbol in the third party library itself.

     

    It fails sometimes and builds other times. I just need to rerun the link
    over and over and eventually it will work.

     

    It is not caused by the explanation you have suggested.

     

    I have opened up a support incident with MS over this. We have already
    determined that the linker is sometimes using an incorrect CRT library, for
    reasons still TBD.

     

    Thanks,
    Nathan

    Tuesday, April 15, 2008 2:59 PM