build errors. First time cmake user
I just downloaded the wireshark source code master V2_4 and did a build with Cmake and got 1206 errors and 600 warnings. This is the base code and I haven't modified any source code to it yet. scanning through the errors, they appeared to be undefined, syntax errors, missing parameters for function calls, etc...
I've been using version 1.12 with nmake for the past several years and thought of upgrading to v24. I created a new directory for version 24, so it should not be sharing the libraries. This is the first time using cmake and I am still using visual studio 10 version which I already have downloaded for the older version. Please suggest. thank you
I have more questions, after building successfully the baseline code wireshark version 2.6 (64bit) and I added a custom dissector in /plugins directory. It built successfully if I did not change the CMakeListsCustom.txt per section 9.2 direction. But did not see the new custom dll in /run/RelWithDebInfo/plugins/2.6. I was expecting the new dll to be there. If I made changes to CMakeListsCustom.txt and added the path to the new custom dissector folder, I could not build, it gave me error in configuration stage. This is the only thing I could not follow from section 9.2 instruction.
Am I missing something here? I read the README.plugins in doc directory, but it seems it is outdated? I could not find epan/gryphon for instance and it did not match instruction on section 9.2.
The question here is I just want to ...(more)
I think I found the new dll's that I added in /run/RelWithDebInfo. But the dll's doesn't seem to dissect when I open the wireshark.exe from this directory. Am I supposed to add these dll's plugins in some other folder? Since in version 1.12.6, there is a wireshark-gtk2 directory where I can test out my dlls. These are the same source code that I ported over from another machine with wireshark version based 1.12.6. which dissects fine with that version, so I am not sure why it did not function in version 2.6. I had to change some prototypes of some functions to upgrade from 1.12.6 to 2.6, but it did build successfully and dlls are generated it seems. Where and how can I test these new dlls? Do you have any idea? thanks
Yes the instructions in 9.2 are required, you must add a CMakeListsCustom.txt with the required path to your custom plugin.
Gryphon has been moved to a built-in dissector, the docs will be updated. Use any other plugin to copy (and modify accordingly) the CMakeLists.txt and plugin.rc.in.
The Wireshark API can and does change between versions, even 2.4 -> 2.6 for instance, so taking code written for 1.12.6 and porting it to 2.6.0 will definitely require changes.
When building a RelWithDebInfo build on Windows, the generated binaries and all supporting files are found in run/RelWithDebInfo. Running Wireshark from that directory will load all the plugins built. If you aren't getting the dissection you expect, then it's likely that you haven't correctly updated the dissector for use with 2.6.0.
Our custom dll is to dissect l2tpv3 frames. It generates the custom dll in the RelWithDebInfo but when open wireshark, it is still dissecting as a default Cisco HDLC frame. Not sure what I'm missing here.Will be looking into this. Was wondering where to add this custom dissector code? Placing in plugins directory did not seem to work. And tried moving under wireshark/plugins/epan doesn't seem to work also. I have a dir path instead of just one file for this custom code.
If the dll appears in the correct place in the RelWithDebInfo directory along with the other plugin dll's, then it is building correctly and it's likely to be code changes in Wireshark that is preventing your plugin from being called.
What does your protocol registration handoff routine look like?
Apparently I was incorrect in a previous comment, Gryphon remains a plugin.
I believe this instruction maybe an issue. This is in
proto_reg_handoff
I saw in gryphon, it uses dissectoraddunitwithpreference. Does the function dissectoradduint needs to be replaced? thanks in advance.
after I changed the function to
dissector_add_uint_with_preference
, the dll did not get generated, instead when I launched the wireshark.exe, it gave me this error for several dlls. Some dlls are not mine, but got this message saying Mutiple problems found. The plugin 'usbdump.dll' has noplugin_version
symbol. and the same errors for ethercat.dll, grpyhon.dll, etc. including my custom dll.oh, I saw my custom dll and gryphon.dll in run/RelWithDebInfo/plugins/2.6/epan instead of under run/RelWithDebInfo. It got generated, but still having issue dissecting. Looking at the packet-l2tp code and realized the
proto_reg_handoff
is the same as my custom dll. I am not sure these 2 source code can co-exist in rel2.6? I have the same code in rel1.12 and it worked fine. My custom dll took precedence over (dont know which dll gets generated for l2tp) if it's there. They both have the sameIP_PROTO_L2TP (115)
for identifier. One other thing in my code is find_dissector function. Does it still work?Ok, my question now is can both dissectors co-exists. As both
proto_reg_handoff_l2tp
andproto_reg_handoff_pmi
(my custom) are trying to register with the sameIP_PROTO_L2TP
it appears the l2tp always took precedence. For some reason, in older version ...(more)AFAIK the order of registration isn't guaranteed. Have you tried disabling the built-in dissector via the GUI option Analyze | Enabled Protocols ?
tried disabling ll2tp protocol from GUI Analyze->EnabledProtocols-> unchecked the l2tp, and the frames are decoded as IPv4 frames instead of custom frames. When I disabled, IPv4 (unchecked this box) and the frmaes are shown as generic Protocol 0x0800. I dont know how to enable the custom protocol.
I wasn't sure if disabling also stopped the registration, apparently it doesn't. I think you'll have to disable the built-in dissector in your build. Comment out the file in epan\dissectors\CMakeLists.txt, regenerate the CMake files and rebuild.
was wondering before changing the build-in dissector, whether wireshark can provide a method to choose the frame preference. For example, in GUI, Edit->Preferences->Portocol->Frame->Treat all frames as L2TP? Currently, there's a way to treat all frames ad docsis frames or not with a box (checked or unchecked). Even if there's no GUI, do you know a source code for this view preferences to treat frames as?
here's one of my
(more)proto_reg_handoff
file looks like. I tried to fix the warnings associated to my file and pretty much cleaned up. But when launched the wireshark I saw Wireshark prompted with "Multiple problems found... The plugin "usbdump.dll" has no "plugin_version symbol...." and similar messages for several of the dlls including mine. And was not sure this is causing my plugin to not recognized by the wireshark. I also downloaded the latest stable release version 2.6 on my pc and added the generated plugins dll's in /plugins/2.6/epan directory, but still did not recognized by the tool. In the old version 1.12, if I placed these dlls in the /plugins/1.12 directory, it works. I can view from Help->About Wireshark->Plugins, the dlls will show up there, but not in 2.6 version.The
proto_reg_handoff_xxx
should look like this:Can you also show:
dissect_3146
functionproto_register_xxx
function that registers the protocol and preferences.The dissection function:
Here's another one with register
That looks OK apart from the superfluous conditionals around the registration calls. No need for that at all.
The fact that you get errors from the distribution provided plugins concerns me. Until you can get a clean build from the unmodified source code that then runs without errors I think you're on shaky ground.
Yes, not sure because I have windows 10 with 64 bit machine and also had to use a different qt version 5.11 instead of 5.9 per Wireshark instruction. I'm getting these warnings in the build regarding unknown option '/Qspectre' in the distributed code.
The QSpectre warnings are because MS has been slow to update VS2015. There has been a recent change to the source to test the flag and only use it if supported.
Qt 5.9 is still available, the online installer gives you the option if you ignore the "Preview" element and expand the "Qt" element.
yes, I tried to download the qt5.9 and got error in installation. That's why I had to use their 5.11 which installed successfully. May try again with qt5.9 later.
FWIW, I currently build with 10.1 with no issues.
yeah, when I added my custom dlls in the downloaded wireshark folder /plugins/2.6/epan and when launch the wireshark, I got the following Multiple problems found. Dont know how to rid of these plugin_version issue.
The plugin 'bdcp.dll' has no "plugin_version" symbol
The plugin 'uepi.dll' has no "plugin_version" symbol
I think that's set by the following lines at the top pf the plugin CMakeLists.txt (from the gryphon plugin):
What do you have there for your errant plugins?
mine is
But remember, I am having errors for plugin version not found for gryphon too when launched the wireshark from run->RelWithDebInfo. If I closed the the wireshark problem box, I can still open pcap files to view. But when I launched from downloaded wireshark tool on my pc, I did not see this error for gryphon.dll, but only for my custom dll. This suggests my build environment may have issue with this plugin_version. Not sure how to fix this.
The resource compiler is used to process the rc.in files and as you had issues with the resource compiler (rc.exe) not being on the path and you copied over the files from the Windows kit, I think that might be causing the plugin issue.
I fear you may have to uninstall VS2015, ensure all traces are removed, and then reinstall. I suppose you could try the repair option.
So, I repaired the VS2015 and that fixed the rc.exe and redl.dll issue. But it did not fix the pluginversion issue. So, I removed the QT version and redownload the Qt 5.10. And rebuilt and now after the build and tried to launch the wireshark from RelWithDebInfo and I got wireshark error window saying Entry Point not found. isRightToLeft@QtPrivate@@YANCQStringView@@@Z could not be located in the dynamic link library. C:\Developement\wireshark\wireshark\run\RelWithDebInfo\Qt5 Gui.dll.
Did you delete your build directory and start again with the new VS and Qt? If not, then some old info will likely be cached.
Delete the build directory (not the source) and re-run the CMake generation step and then the build.
I deleted the zlib folders and rebuilt and that seems to have solved the issue. Right now, it generated dll's fine,but still having issue when launching the wireshark it did not seem to recognize the custom dlls. I added these custom dlls in /wireshark26/plugins/2.6/epan and also in /wireshark26/plugins and also directly under wireshark26, but still it did not recognize the custom.dlls. In the Help menu under Plugins I can see the other dll's such as ehtercat.dll, gryphon.dll, wimax.dll etc, but not the custom ones. I dont know how to make these custom dlls to take into effect. This wasn't an issue in version 1.12.6 when I placed these custom dlls under /wireshark/plugins folder. Another difference is that the 1.12.6 custom dlls are generated with windows7 64 ...(more)
If you have correctly added your custom plugins to the build system, then they will be automagically copied to the correct place in the run directory. Having to manually copy them indicates that you haven't correctly added them to the build system.
It's not clear to me, but are you copying the custom dll's from a 1.12.6 build into a 2.6 build? If so, that won't work at all. You must build the plugins for 2.6 by adding the source code to the build.
I really do recommend deleting the build directory and regenerating and building again.
sorry that I did not explained clearly. I have 2 virtual machines, one with windows7 wireshark version 1.12.6 which have the custom dlls working for more than 4-5 years and I am saving this as is, since this one works for sure.
I just copied those dlls source code to a new virtual machine which has windows 10 and wireshark base code verion 2.6. Which I am having issues with the custom dlls to get recognized by wireshark tool. The custom dlls are generated as expected under run/RelWithDebInfo/plugins/2.6/epan. I can see my dlls along with others under this directory.
What I am trying to say was I have a wireshark version 2.6 installed on my pc and when I copied these generated custom dll's from my virtual machine to my pc, I manually added to plugin directory like I did ...(more)
No
plugin_version
symbol for the custom dlls are still an issue when wireshark is launched. This is after repairing VS15, reloaded Qt version 5.10.1, clean up build directory and rebuilt and the custom dlls are generated and found under run/RelWithDebInfo/plugins/2.6/epan. This maybe an issue with wireshark not recognizing the custom dlls. I am at lost at this moment how to fix this plugin_version issue since I made the same as other plugins. my build had this problem for all other plugins as well as my custom plugins. But if I launched the downloaded wireshark, it only complains for my custom.dlls suggesting there may still be an issue with the build.I think the
plugin_version
is indeed the issue, as the plugin loader looks for that to determine a dll is actually a plugin.We'll need to see your build output to determine what's wrong. Please use the following command to generate a build log (build.txt) and share that logfile publicly, e.g. Google Drive, DropBox etc.:
https://drive.google.com/file/d/1TcUr...
let me know if you have issue viewing this build.txt file. thanks for your help.
Comparing the output of building the gryphon plugin and one of your custom ones (bdcp) shows that you have a few warnings to fix:
the latter of these is very important and
However, these don't seem to be indicative of your issue with loading. Can you check the exported symbols from your ...(more)
The warnings for bdcp are old code and no longer used. That's why I did not fix, but will comment the code later. Here's the output of the command.
Dump of file C:\Development\wireshark\run\RelWithDebInfo\plugins\2.6\epan\bdcp.dll
File Type: DLL
Section contains the following exports for bdcp.dll
Summary
And comparing the output for the gryphon plugin you can see that your plugin isn't exporting 2 of the 3 required symbols:
These symbols are added to your plugin by code in the cmake module "cmake\modules\UseMakePluginReg.cmake" which generates a plugin.c file in the build directory of your plugin, so for bdcp it's in C:\Development\wireshark\plugins\epan\BDCP. Can you show the contents of that file?
This is the generated plugin.c file from C:\Development\wireshark\plugins\epan\BDCP.
Does it matter where the custom source code is? I had it under plugins/epan/... instead of directly under plugins. These are defined in CMakeListCustom.txt in wireshark dir. Do I need to make changes to Custom.m4 and Custom.make files under plugins directory?
The plugin.c file is missing the version and release definitions. The gryphon version has these:
Somehow your plugin.c was generated incorrectly. Can you delete it and then rerun the build of the plugins, again redirecting output to a file and share that file?
Compare the plugin.c for your plugin with that of the gryphon one.
You no longer need the Custom.m4 and Custom.make files, they aren't used. You source code is OK where you have put it.
Also note that you can format comments by highlighting the appropriate parts and using the formatting buttons at the top of the editing box. This is especially useful for code.
Here's the output. plugin.txt on google drive. https://drive.google.com/file/d/1ah6e...
I'm not sure you noticed, I also created a foo.dll with not much code in it, just to test the export part. But unable to. It seems all the plugins from my build appeared to have the plug in version issue. I just looked at the plugin.c for gryphon and it also has those missing 2 items from my build.
So, I am about to experiment on my other virtual machine with windows 7 sometime(possibly weekends) to make a build and test this issue. thank you so much for helping me.
this is from plugin.c file for foo.dll:
(more)Yep, that's missing the required symbols. I'm absolutely baffled as to how they are omitted. The plugin.c file is generated by a python script (tools\make-plugin-reg.py) and that writes out the following code all in one go:
so why are the lines missing? In the build output I saw bdcp\plugin.c being generated, can you check that file again?
OK, crazy guess time, can you ensure that you don't have a plugin.c sitting in the source code directory next to packet-BDCP.c?
I don't think there's much point comparing the old 1.12.6 build system to the current one, they're entirely different.
yes, there's a plugin.c file sitting next to source code. That's what I copied and pasted on my previous comment. and I just checked and that was generated yet again in the source code directory with the same output. Those 2 lines are still missing. For the experiment this weekend, I was about to convert the code in that windows7 machine to version 2.6 and follow the same process as this one.
I see plugin.c file being generated for gryphon source directory as well. I always run "msbuild /m /p:Configuration=RelWithDebInfo Wireshark.sln /t:Clean" so the plugin.c file is removed first. Where is the generated plugin.c file supposed to be if not in the source directory wireshark/plugins/epan/gryphon.
In the source code directory, next to packet-bdcp.c? Hold on, are you attempting an in-tree build, if so they have never been tested?
Where is your source tree, C:\Development\Wireshark? And where is your build tree?
As per the developers guide, you should create a separate directory for the build tree, e.g. c:\Development\wsbuild64, cd into that directory and generate the build files.
yes in tree. I did try earlier with wsbuild64 but with other errors I went back to in tree. I can try the wsbuild64 again.
As you've found out, in-tree builds are not a good idea, hence why the developers guide says to do an out-of-tree build. Please try with wsbuild64.
ok, I remembered now. when I tried to generate build under wsbuild64, it gave me error as below.
C:\Development\wsbuild64>"C:\Program Files\CMake\bin\cmake.exe" -DENABLECHMGUIDES=on -G "Visual Studio 14 2015 Win64" CMake Error: The source directory "C:/Development/wsbuild64" does not appear to contain CMakeLists.txt. Specify --help for usage, or press the help button on the CMake GUI.
Because you've failed to read the developers guide correctly, you should be using:
Note the path to wireshark has a leading "..\" to move up one level and then into the wireshark source directory. This assumes you have a structure similar to that proposed in the Developers Guide:
ok, got it. hope this will fix the plugin version issue. Will let you know. And thank you for all your help.
sorry to have to inform you that the plugin_version issue still persist with building in ws64build directory as well. The plugin.c files are now in this build directory under Development\wsbuild64\plugins\epan\gryphon. but those 2 lines are still missing.
I'm baffled. Can you share what you have in the source tools\make-plugin-reg.py?
I do think that your source directory might have been "corrupted" by the in-tree build attempt. You might be best deleting it (and the build directory) and recreating them. If you do this, try just building from the plain sources without your plugin additions first and check to see what's in the gryphon generated copy of plugin.c.
here's the link to make-plugin-reg.py https://drive.google.com/file/d/1ah6e...
Yes, that's what I'm guessing. I will try to start from clean baseline code. Since it is also corrupting the gryphon.dll and other dlls plugin versions that comes with the baseline code.
The last link seems to be plugins.txt. I was wanting the actual contents of make-plugin-reg.py.
sorry, here it is. https://drive.google.com/file/d/12QSp...
Your version of make-plugin-reg.py is missing the required lines!!!
What is the "source" of your source? Git or a tarball? If git, what branch are you using, if a tarball, which source version?
I used git extension to clone the branch master-2.6
Sorry!!!! I found out after looking through my notes. I removed those 2 lines from that file. I will add that back in. That was when I was having some issue.