using ddk to link mingw64 libraries

2009-03-02
2013-06-06
  • Brian Hawley
    Brian Hawley
    2009-03-02

    We have built our libraries using mingw64, and in some cases are needing to use the native DDK to create the final binary .exe.

    However, we are seeing unresolved symbol warnings (which we do not see when using the 32 bit version).  This is only one of them, but all references to functions in the library are being reported as unresolved.

    csi_ccwl.obj : error LNK2019: unresolved external symbol delete__LUCI referenced
    in function new__CSI

    Here is an excerpt from the 64 bit produced library run through ranlib (from the mingw64 bit binaries)...

    0000000000000310 T _delete__LUCI^M
                  
    0000000000000490 T _new__LUCI^M

    And here is an excerpt from the nm output on the object file referencing these library functions:

    0000000000000000 T delete__CSI^M
                     U delete__LError^M
                     U delete__LUCI^M

    When doing final linking, it can not find either of these (or basically any function).  However, when using the native DDK to link against the same libraries (32 bit variant) to generate a 32 bit executable we do not have this problem.

    Here is the DDK link line...it is very similar to the 32 bit, except the 64 bit libraries being specified...

    set compPath=c:\WINDDK\6001
    rem set compPath=d:\compiler\ddk80^M
    ^M
    set luminex_lib=libluci_K64.a
    set oce_obj=entry.obj os.obj svc.obj li.obj csi_ccwl.obj csi_uci.obj   csimsg.re
    s^M
    ^M
    %compPath%\bin\win64\x86\amd64\link.exe /nologo /WX -MERGE:_PAGE=PAGE -MERGE:_TE
    XT=.text -SECTION:INIT,d -OPT:REF -OPT:ICF -INCREMENTAL:NO -FULLBUILD /release -
    debugtype:cv    -IGNORE:4010,4037,4039,4065,4070,4078,4087,4089,4198,4221   -NOD
    EFAULTLIB ntoskrnl.lib hal.lib wmilib.lib -version:5.1 -osversion:5.1 /opt:nowin
    98 -driver -subsystem:native,5.01 -entry:DriverEntry -STACK:0x40000,0x1000 -base
    :0x10000 -align:0x80 -machine:amd64  %luminex_lib%  /LIBPATH:%compPath%\Lib\wnet
    \amd64 %oce_obj%  /out:ficon.sys  /DEBUG /pdb:ficon.pdb hotpatch.obj BufferOverf
    lowK.lib^M
    ^M
    pause^M

    Any ideas would be greatly appreciated.

     
    • Brian Hawley
      Brian Hawley
      2009-03-03

      On closer inspection, I think the caller of the library functions is not assuming a C calling convention (i.e. _cdecl), hence no leading underscore. 

       
    • Brian Hawley
      Brian Hawley
      2009-03-03

      On closer inspection, I think the caller of the library functions is not assuming a C calling convention (i.e. _cdecl), hence no leading underscore. 

       
    • Brian Hawley
      Brian Hawley
      2009-03-03

      After some testing, I've determined that while it might not be cdecl, it isn't stdcall either.

      if i build the libraries using stdcall definition, then the @XX is appended to the names.

      Also, under the 32 bit native ddk builds, with both the library function and the extern definition specifying _cdecl, the libraries resolve and an nm on the .obj and the .a file confirm that the function appears as _new__LUCI

      under the 64 bit native ddk builds, I can confirm using nm that the function appears as _new__LUCI  (so the library has compiled with what it believes is cdecl convention.  however attempting to use nm on the .obj file reports a 'file truncated' error.

      I am using the 6001 DDK in the Windows Server 2003 x64 free build environment.

      Why isn't the obj file being decorated with the leading _....and why is driver.obj reporting as truncted.

      any help would be appreciated.

      thanks.

       
    • Brian Hawley
      Brian Hawley
      2009-03-03

      Sorry for the multiple posts.  I couldn't find an edit, or delete.

      After additional research (and eventually finding a reasonable set of search keywords) I have concluded the following:

      1) the native x64 build environment does not use the leading underscore for cdecl.

      2) using the -fno-leading-underscore option when building the libraries appears to allow us to do a final link (with the exception of KeGetCurrentThread...have to do more research on that).

      Unfortunately the mother board in our 64 bit system blew up, so I haven't been able to test the resulting binary/driver.

      The only problem with using the -fno-leading-underscore is that we now can not use those same libraries to link using mingw64 to produce binaries.  the compiler spits out lots of stuff like:

      undefined reference to `strlen'

      and can't find any of the _imp functions

      the reason for this is obvious...the 64 bit defs/libraries all have the leading underscore.

      I'm wondering if the appropriate course of action is to rebuild them and remove the leading underscore, or if there is better  course of action.  This seems like it has come up a few other times with other libraries.