This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

How to solve error C2099 and LNK2019 when building dissector plugin on Windows 7 64bit?

Hi all, I am using the up-to-date Wireshark source and I was able to build WS on Windows 7 64bit ok. Now I wanted to start with a dissector plugin. For the first try I started with a built-in dissector called packet-mqtt.c and copied that as packet-mqttmod.c to the plugin location. Following the steps in README.plugins.

I didn't change anything in the code except the names from mqtt and MQTT to mqttmod to MQTTMOD so I know it is "my" dissector. When I try to build, I get the following error:

C:\Development\wireshark\plugins\mqttmod\packet-mqttmod.c(569): error C2099: initializer is not a constant [c:\Development\wsbuild64\plugins\mqttmod\mqttmod.vcxproj]

If I comment out the error causing code to see if the rest runs through, I get another error:

(Link target) -> packet-mqttmod.obj : error LNK2019: unresolved external symbol dissect_uleb128 referenced in function dissect_mqttmod [c:\Development\wsbuild64\plugins\mqttmod\mqttmod.vcxproj] C:\Development\wsbuild64\run\RelWithDebInfo\plugins\mqttmod.dll : fatal error LNK1120: 1 unresolved externals [c:\Development\wsbuild64\plugins\mqttmod\mqttmod.vcxproj]

At least for the second error I found that this is related to dwarf.h/dwarf.c, but I could not find out in which library this is compiled and spot the correct *.lib file. And then still I would not know how to satisfy this dependency for the build.

I'd appreciate any suggestions. Best regards, Mike

windows7 dissector linker 64-bit plugin

asked 13 Apr '16, 02:15

mikethebo
21●4●4●7
accept rate: 0%

One Answer:

Not sure about the first error, what version of Visual Studio are you using?

For the second, the function dissect_uleb128() is in libwireshark, but it isn't exported so can't be linked to by a plugin in a separate DLL. To export the function, add WS_DLL_PUBLIC to the declaration in dwarf.h.

Edit dwarf.h will also need to #include "ws_symbol_export.h" to get the correct declaration of WS_DLL_PUBLIC.

answered 13 Apr '16, 03:35

grahamb ♦
19.8k●3●30●206
accept rate: 22%

edited 13 Apr '16, 07:46

Yes sorry I forgot. I am using VS2013 and I am setting all environment variables accordingly.

(13 Apr '16, 07:24) mikethebo

As the files compiles quite happily in its normal place I suspect it's something else that isn't ex\imported. Maybe tfs_set_notset, although that is marked as WS_DLL_PUBLIC

Also note my edit about dwarf.h above.

(13 Apr '16, 07:44) grahamb ♦

This solved the linker error. Thank you. Funny things is, that the first error is related to TFS(&tfs_set_notset). From what I found with google the const char in the typedef of tfs.h might be the cause. If I pass NULL instead of TFS(&tfs_set_notset) it is fine.

(14 Apr '16, 00:55) mikethebo

If I remember correctly there is a problem with using global tfs strings on Windows in plugins, somting with DATA and inter dll. You'll be better of defining them locally.

(14 Apr '16, 01:42) Anders ♦

Also check comment in this question for the C2099 error when compiling for Windows.

(22 Apr '16, 10:03) mikethebo