Thanks Michael. Could this be done as an additional function in the plugin_if
family?
Sent from Samsung Mobile on O2
Original message
From: Michael Mann via Wireshark-dev
Date: 28/07/2017 18:53 (GMT+00:00)
To: wireshark-dev@wireshark.org
Cc: Michael Mann
Subject: Re: [Wire
Yes I am building a plugin.
Sent from Samsung Mobile on O2
Original message
From: Pascal Quantin
Date: 28/07/2017 18:41 (GMT+00:00)
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] LNK2019: unresolved external symbol
proto_deregister_protocol
Hi Paul,
See some discussion on the issue here: https://code.wireshark.org/review/21490/
-Original Message-
From: Pascal Quantin
To: Developer support list for Wireshark
Sent: Fri, Jul 28, 2017 1:41 pm
Subject: Re: [Wireshark-dev] LNK2019: unresolved external symbol
proto_deregister_protocol
Hi Paul,
2017-07-28 19:34 GMT+02:00 Paul Offord :
> Hi,
>
>
>
> I’d like to use the function proto_deregister_protocol in a dissector.
> The problem is that when I build the dissector I get:
>
>
>
> packet-bds.obj : error LNK2019: unresolved external symbol
> proto_deregister_protocol referenced
Hi,
I'd like to use the function proto_deregister_protocol in a dissector. The
problem is that when I build the dissector I get:
packet-bds.obj : error LNK2019: unresolved external symbol
proto_deregister_protocol referenced in function clean_up
I've included proto.h in the source code. Why
I am currently on it. Apparently I invoked a hidden bug in HAVE_PCAP
availability.
Cheers
> Am 28.07.2017 um 00:15 schrieb Gisle Vanem :
>
> Dario Lombardo wrote:
>
> > The current master can't build if we disable PCAP in cmake.
>
> I can't be build if HAVE_EXTCAP is not defined either
>
>
Hello,
I have built 2.2.0, 2.2.1, 2.2.5 with no problems.
I unpacked 2.4.0 source and created a build directory ws240-64.
The first issue was a complaint about cmake version 3.5 not being good enough.
I have now installed cmake 3.8.2 which fixed the previous problem. (Thank you
Pascal Quantin)
I’ve found a bug in the CMake (build file generation) process on Win64 targets,
which causes the redefinition of the CYGWIN_INSTALL_PATH variable partway
through the build file generation. This bug originally manifested when CMake
was unable to locate the SH_EXECUTABLE file in the C:\Cygwin64 di
I would not distinguish between self-builds and buildbot builds. There are
extcap developers out there, who use the released Wireshark version to
develop extcap interfaces and also would benefit greatly from using such
debug scenarios. And I would not want to tell them to explicitly build a
develop
