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. 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 edited 29 Aug '13, 15:08  Guy Harris ♦♦ |
One Answer:
The GLib reference, with its lack of a "since 2.x" item for I've filed bug 707092 in the GNOME bug database for the documentation's apparent lack of an indication of 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 answered 29 Aug '13, 15:52 Guy Harris ♦♦ 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.
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.)