I will check out if GLIB2 is really necessary for windows and make it
conditionally if so.
And yes I'm intended to make the tool working in Linux and FreeBSD too.
Because it is only using a socket connection to the device, it should be
easy to get it working for any platform.
The hardest pla
That is in fact the correct solution. I am not really sure why
GLIB2_LIBRARIES is needed in this general way, but you will always have to
look at your cmake files from a cross-plattform POV to ensure, that your
utility is being built on all platforms. It is strongly recommended, that
you build your
On 5-1-2019 22:20, Guy Harris wrote:
On Jan 5, 2019, at 1:08 PM, hdv wrote:
wsutil is already in the dependency list. So its not in there.
Please send us your modified version of extcap/CMakeLists.txt.
I fixed it: the function is in 'ws2_32' and I added it conditionally as
follow in my "sn
On Jan 5, 2019, at 1:08 PM, hdv wrote:
> wsutil is already in the dependency list. So its not in there.
Please send us your modified version of extcap/CMakeLists.txt.
___
Sent via:Wireshark-dev mailing list
Archives:
On 5-1-2019 18:56, Guy Harris wrote:
On Jan 5, 2019, at 7:29 AM, hdv wrote:
Ok, I assume there *could* be a binary (static) lib distributed with Wireshark, so it is
not the case apparently. So I don't have to search for the problem there. The makefiles
refer to "GLIB2_LIBRARIES" I assumed t
On Jan 5, 2019, at 7:29 AM, hdv wrote:
> Ok, I assume there *could* be a binary (static) lib distributed with
> Wireshark, so it is not the case apparently. So I don't have to search for
> the problem there. The makefiles refer to "GLIB2_LIBRARIES" I assumed these
> to be the standard library.
On 5-1-2019 00:05, Guy Harris wrote:
On Jan 4, 2019, at 2:38 PM, hdv wrote:
I'm not a guru on CMake, so no idea if the libraries are binary loaded
(probably) or built locally. I even don't know in which lib it was before, it
just worked and now this surprises me. I followed the installation
On Jan 4, 2019, at 2:38 PM, hdv wrote:
> I'm not a guru on CMake, so no idea if the libraries are binary loaded
> (probably) or built locally. I even don't know in which lib it was before, it
> just worked and now this surprises me. I followed the installation
> instructions (more or less) for
On 4-1-2019 21:53, Guy Harris wrote:
On Jan 4, 2019, at 3:59 AM, hdv wrote:
In the extcap plugin I'm developing I used the getaddrinfo() call to resolve
hostnames. This should be favorable over gethostname() which is actually
deprecated AFAIK.
The previous commit I was developing on was ar
On Jan 4, 2019, at 3:59 AM, hdv wrote:
> In the extcap plugin I'm developing I used the getaddrinfo() call to resolve
> hostnames. This should be favorable over gethostname() which is actually
> deprecated AFAIK.
>
> The previous commit I was developing on was around june 14th, 2018
> (27a190
On 4-1-2019 12:59, hdv wrote:
Hi,
In the extcap plugin I'm developing I used the getaddrinfo() call to
resolve hostnames. This should be favorable over gethostname() which
is actually deprecated AFAIK.
Ofcourse I mean: gethostbyname().
The previous commit I was developing on was around jun
Hi,
In the extcap plugin I'm developing I used the getaddrinfo() call to
resolve hostnames. This should be favorable over gethostname() which is
actually deprecated AFAIK.
The previous commit I was developing on was around june 14th, 2018
(27a1906c582b..) where it still worked, now after reb
12 matches
Mail list logo
