Win7 64-bit .dll failure at runtime

2010-10-06
2013-06-06
  • Sly Technologies

    Hello,
      My project uses WinPcap native library on windows 32 and 64-bits. I've recently switched to mingw-w64 toolchain, but I can't seem to get the linking of my existing code right with latest WinPcap x64 code (http://winpcap.org).

    I can compile and link using the development package WpdPack 4.1.2. The runtime has compatible WinPcap 4.1.2 installed under \windows\system32 and \windows\SysWOW64. WinPcap is a widely used project, so I'm sure their libraries and DLLs are working correctly.

    Any call made to their library (which g++ compiler seems to have linked with WpdPack library) core-dumps immediately. Here is a simple example that will coredump:

    const char *name = pcap_datalink_val_to_name(1);

    The exception thrown is 'siginfo: ExceptionCode=0xc0000005' reading address 0x.00000000c76cea4e which corresponds to address linked, the same as when I display it before making the call with printf("%p\n", pcap_datalink_val_to_name). So the libraries think the addresses are resolved, but obviously something goes wrong as that address is readonly-protected?

    I'm keeping a blog on this issue. It has a more detailed stack trace and dll walker dump of the finished dll I compiled.

    http://jnetpcap.com/node/662

    Lastly here are the g++ command line args for the linking process:

    g++ -shared -g -Wl -add-stdcall-alias -static-libgcc -o ./build/lib/jnetpcap.dll (bunch of .o files) -L ./lib/WpdPack_4_1_2/WpdPack/Lib/x64 -l wpcap -l IPHlpApi

    Thanks for the help,
    mark…

     
  • Ozkan Sezer

    Ozkan Sezer - 2010-10-06

    What is the exact import library you are using for linkage to wpcap.dll:
    If it is an msvc import library, ie. wpcap.lib, the linkage will succeed
    but a bad binary will be generated.  If this is the case, you should use
    a native libwpcap.a import library with gcc and ld:

    Take the x64 version of your wpcap.dll, do:

    gendef wpcap.dll
    

    … then run:

    dlltool --as-flags=--64 -m i386:x86-64 -k --output-lib libwpcap.a --input-def wpcap.def
    

    .. and use the generated libwpcap.a for the linkage.

    Hope this helps.

     
  • Sly Technologies

    Got it. I was linking against the wpcap.lib file. in x64 directory.

    I generated the libwpcap.a file as per your instructions, but how do I force g++ to link using the .a instead of the .lib?

     
  • Sly Technologies

    The WpdPack 4.1.2 library comes as follows:

    wpdpack/lib
       libpacket.a
       libwpcap.a
       Packet.lib
       wpcap.lib
        x64/ Packet.lib
        x64/  wpcap.lib
    

    The do provide the libwpcap.a file, but that is the 32-bit version? I can't use that right. I can add those dlltool generation into the build script to regenerate the x64 bit libpcap.a file everytime if needed.

     
  • Ozkan Sezer

    Ozkan Sezer - 2010-10-06

    Your command line shows that wpcap.lib is under :
    ./lib/WpdPack_4_1_2/WpdPack/Lib/x64

    Just put the new libwpcap.a under that same directory and gcc will hit that *.a file first rather than the *.lib variant.  In case that doesn't work (it should work), then just put it in some other directory of its own and change the directory that you pass to the -L option to that new one.

     
  • Ozkan Sezer

    Ozkan Sezer - 2010-10-06

    Yes, wpdpack/lib/libwpcap.a must be the x86 version, you can't use it for x64.

    Just put your newly generated x64 version of libwpcap.a under that
    wpdpack/lib/x64 directory and you should be good to go.

     
  • Sly Technologies

    You are right. It did choose the .a over the .lib file.

    It works. All my jUnit test cases pass - thank you.

    A last question, so that I understand this correctly.

    If it is an msvc import library, ie. wpcap.lib, the linkage will succeed but a bad binary will be generated.  If this is the case, you should use

    Why is the bad binary being generated? Is this a gcc issue or the WinPcap wpcap.dll generated wrong?

     
  • Ozkan Sezer

    Ozkan Sezer - 2010-10-06

    > You are right. It did choose the .a over the .lib file.
    >
    > It works. All my jUnit test cases pass - thank you.
    >

    Nice! This is good to know.

    > A last question, so that I understand this correctly.
    >
    >

    > If it is an msvc import library, ie. wpcap.lib, the linkage
    > will succeed but a bad binary will be generated.  If this is
    > the case, you should use

    >
    > Why is the bad binary being generated? Is this a gcc issue
    > or the WinPcap wpcap.dll generated wrong?

    Oh, that's just a binutils issue.  To be fixed (implemented)
    _hopefully_ soon.

     
  • Sly Technologies

    Again, thanks for all your help.

    I think I got a handle on this now. Until this is properly fixed in "binutils", I will add the work around into my build script which already generates plenty of various code on the fly anyway. So I have  a perfect place to put this .a file during build process.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks