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

g_close not being recognized as available function in plugin dissector

0

I'm writing a plugin dissector that upon initialization reads a file with a 64bit key and a string to be stored in a hash table. This gets used to identify messages.

I've written code in the dissector that uses g_close and strtoll to close the file and read the 64 bit key. The code has the following includes.

#include <glib.h>
#include <glib/gstdio.h>

I'm getting the build error message warning C4013: 'g_close' undefined; assuming extern returning int

As well as the following linker error

tomato.obj : error LNK2019: unresolved external symbol _g_close referenced in function _loadTheOM

Tomato_v1.0.0-603_ws1_8.dll : fatal error LNK1120: 1 unresolved externals

The error leads me to believe that I'm not including the correct files. But the GLib reference leads me to believe that I'm including the correct file. Other glib functions such as g_ascii_strtoll seem to build and link correctly.

I'm on Win7 and use VS2010. Is there some sort of Makefile line I need to edit?

asked 29 Aug '13, 14:21

tlann's gravatar image

tlann
76121419
accept rate: 100%

edited 29 Aug '13, 15:08

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196


One Answer:

1

The GLib reference, with its lack of a "since 2.x" item for g_close(), also can lead one to believe, not inappropriately, that it's available in all versions of GLib 2.x; however, a quick look at the GLib 2.34.3 source seems to indicate that it's not available in that version. It appears to have been introduced somewhere in the 2.35 or 2.36 version; the header file seems to say it's only available in 2.36.

I've filed bug 707092 in the GNOME bug database for the documentation's apparent lack of an indication of g_close()'s availability.

I don't know what GLib version the Wireshark Windows build process installs by default, but if it's before 2.35, and possibly even if it is 2.35.x, that might not make g_close() available.

answered 29 Aug '13, 15:52

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196
accept rate: 19%

edited 29 Aug '13, 15:59

Thanks for your help and editing my question. I thought the 4 spaces should of made my code display correctly. After looking at it again I guess I could of selected it and used control k.

(29 Aug '13, 15:59) tlann
1

It did make it display correctly once I edited the question to put them in, and probably would have made it display correctly once you posted your question. However, while I was editing it, the preview display didn't show anything after #include, and you would have seen the same thing, which could have led you to believe that it wouldn't work when you posted the question. (As I said in my edit comment, previewing in the version of the OSQA that this site uses doesn't always work correctly; I don't know whether a later version of OSQA fixes it or not. I suspect that the server-side code that generates the formatted version of questions, comments, and answers isn't JavaScript and that the previewing code is JavaScript; if so, the previewing isn't being done by the same code that will actually generate the formatted version, so, unless the authors are careful, the two versions of the code could generate different results.)

(29 Aug '13, 16:05) Guy Harris ♦♦