none
libgw32c.lib(hxstat64.o) : error LNK2001: unresolved external symbol ___udivdi3

    Question

  • Hi,

     

    While compiling one of our application we are getting below errors related to libgw32.c.lib library.

    We were able to succed in compiling few of the modules using libgw32.c.lib without any errors.

    But the below errors are generating for one module.

     

    ----------------------------------------------------------------------------------------------------------------------

    libgw32c.lib(hxstat64.o) : error LNK2001: unresolved external symbol ___udivdi3

    libgw32c.lib(statfsx64.o) : error LNK2001: unresolved external symbol ___udivdi3

    libgw32c.lib(tempname.o) : error LNK2001: unresolved external symbol ___udivdi3

    libgw32c.lib(getntptimeofday.o) : error LNK2001: unresolved external symbol ___udivdi3

    libgw32c.lib(tempname.o) : error LNK2001: unresolved external symbol ___umoddi3

    libgw32c.lib(getntptimeofday.o) : error LNK2001: unresolved external symbol ___umoddi3

    libgw32c.lib(readlink.o) : error LNK2001: unresolved external symbol __alloca

    d:\data\198590002\My Documents\Visual Studio 2005\Projects\AUDIT_COSOL-DUPLICATE\Release\AUDIT_COSOL-DUPLICATE.exe : fatal error LNK1120: 3 unresolved externals

    ----------------------------------------------------------------------------------------------------------------------

     

    We had google for the above errors and got an answer from this site http://www.opensc-project.org/pipermail/opensc-devel/2005-October/007495.html, we have downloaded libltdl.lib and added onto our project. After adding libltdl.lib  it is saying the library is corrupted.

    Linking.....\..\..\..\..\Desktop\AUDIT-CONSOL\ltdl-bcc.lib : fatal error LNK1136: invalid or corrupt file

     

    We had sent an email to the owner of ltdl-bcc.lib and waiting for a new library from them.

     

    We are curious to know are there any other solutions to resolve these issues.

     

    Thanks.

    Wednesday, March 19, 2008 9:05 PM

Answers

  • That is normal.

    When you use a static lib, the linker will strip everything from it that it does not need to limit the size of the final executable.

     

    This means that if your c files have no direct or indirect need for the missing symbols, you will never know they were missing. Only if they are needed (direct or indirect) because of a function call in your module will the linker discover that they are missing.

     

    so:

    a) which C runtime do you link to (perhaps you could post the linker command line from your buildlog.htm file)

    b) is that corrupt lib compiled with the same version of the compiler (incl service pack) that you use?

    Friday, March 21, 2008 12:21 PM
  • This sounds very much like GCC code (note the .o extension instead of .obj) and the unresolved symbols are part of the compiler support library (libgcc IIRC)

     

    Generally it is not a good idea to use mismatching toolchains (the ones that were used to build the object files and the one you are linking with).

     

    If there is any chance you can rebuild things with VC++ you should do so (the rule of thumb is never mix object files -- including static libs from different compiler toolchains or different build configurations in a single executable image)

     

    If you just need to use a small defined set of functionality and can easily define a binary interface you could wrap the existing library with a compatible compiler toolchain (I suspect this is some MingW toolchain) in a DLL. If you define the interface carefully (make sure compiler toolchains agree on the binary layout of types in the interface) you can consume the DLL from VC++.

     

    -hg

    Friday, March 21, 2008 4:28 PM

All replies

  •  

    Are you using the correct version of Visual Studio?

    static libraries have to be used with the same compiler version that was used to create them.

    If you use the wrong version, or even the wrong service pack, then this is one of the things that might happen.

     

    Also, are you linking to the correct C runtime library?

    Thursday, March 20, 2008 10:17 AM
  • We are using VS studio 2005 .Net 2.0.

     

    We were able to succed in compiling few of the modules using libgw32.c.lib without any errors.

    But those errors are generating for only one module.

    Thursday, March 20, 2008 12:51 PM
  • That is normal.

    When you use a static lib, the linker will strip everything from it that it does not need to limit the size of the final executable.

     

    This means that if your c files have no direct or indirect need for the missing symbols, you will never know they were missing. Only if they are needed (direct or indirect) because of a function call in your module will the linker discover that they are missing.

     

    so:

    a) which C runtime do you link to (perhaps you could post the linker command line from your buildlog.htm file)

    b) is that corrupt lib compiled with the same version of the compiler (incl service pack) that you use?

    Friday, March 21, 2008 12:21 PM
  • This sounds very much like GCC code (note the .o extension instead of .obj) and the unresolved symbols are part of the compiler support library (libgcc IIRC)

     

    Generally it is not a good idea to use mismatching toolchains (the ones that were used to build the object files and the one you are linking with).

     

    If there is any chance you can rebuild things with VC++ you should do so (the rule of thumb is never mix object files -- including static libs from different compiler toolchains or different build configurations in a single executable image)

     

    If you just need to use a small defined set of functionality and can easily define a binary interface you could wrap the existing library with a compatible compiler toolchain (I suspect this is some MingW toolchain) in a DLL. If you define the interface carefully (make sure compiler toolchains agree on the binary layout of types in the interface) you can consume the DLL from VC++.

     

    -hg

    Friday, March 21, 2008 4:28 PM