I just ran across the same problem and I was able to solve this by compiling my plugins with a "/MT" flag.
Ulf Lamping wrote: > Chris Delaney wrote: > >> Thank you for the response. I tried both of your suggestions, but the >> problem remains. The xxx.dll.manifest file was generated during the >> build, but copying it to the .../plugins/0.99.5 directory did not >> allow the plugin to be loaded. Also, the machine I am trying to run >> the WS distribution is the same as where VC is installed, but I >> installed vcredist_x86.exe anyway and again, the plugin failed to load. >> >> One thing I did notice was that the .dll's included with the general >> distribution require these .dll's: >> >> libwireshark.dll >> MSVCRT.dll >> KERNEL32.dll >> >> The .dll's that I create with MSVC05EE require these .dll's: >> >> libwireshark.dll >> MSVCR80.dll >> KERNEL32.dll >> > That's what I would expect. > >> I have the C runtime library MSVCRT.dll in my system32 directory, but >> I do not have MSVCR80.dll anywhere within my library path, despite >> having installed vcredist_x86.exe, and MSVC05EE. >> > You should find at least one appearance of MSVCR80.dll in one of the > c:\windows\SxS folders, that's where Studio and vcredist_x86.exe will > install it into. The SxS folders are a new MS way to prevent the DLL > hell, but I don't know much more about this feature. > >> After I copied MSVCR80.dll into my system32 directory, the error >> message changed: >> >> From: >> Couldn't load module <path>\xxx.dll: The specified module could not be >> found. >> >> To: >> Couldn't load module <path>\xxx.dll: The specified procedure could not >> be found. >> >> So it seems that the MS C Runtime Library is at fault here, but I >> still can't seem to nail down the issue. Is there a dependency that >> .dll's compiled with MSVC05EE are not compatible with a .exe compiled >> with MSVC06? >> >> > Yes and no. It should be possible (we use the GTK dlls that are compiled > with MSVC6 with the MSVC2005EE studio builds - so mixing Dlls is > possible), but you have to be very careful about passing C runtime > resources (e.g. FILE handles) between these two, but that's usually not > a problem for a typical dissector. But this will make problems while > running WS, not while loading it (as you have). > > I'm unsure what the real problem is here. In an attempt to find the > cause you may try to strip down the plugin content to an absolute > minimum content (e.g. #if 0 out all "functional" parts) and see if this > fixes your problem - in this case a call within your dissector code is > the problem.. > > The only solution that should work is to use the MSVC2005EE generated > Wireshark instead of the official one. > > Regards, ULFL > _______________________________________________ > Wireshark-dev mailing list > [email protected] > http://www.wireshark.org/mailman/listinfo/wireshark-dev > _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
