On Sat, Feb 21, 2004 at 06:06:25PM +0100, Gisle Vanem wrote: > While linking dftest.exe with MingW: > > packet-diameter.o(.text+0x48c7): In function `xmlParseFilePush': > G:/MingW32/src/inet/Ethereal-0.10.1/packet-diameter.c:286: undefined reference to > `report_open_failure' > > epan/ethereal.a(plugins.o)(.data+0x3e8): In function `plugins_scan_dir': > G:/MingW32/src/inet/Ethereal-0.10.1/epan/plugins.c:226: undefined reference to > `report_open_failure' > epan/ethereal.a(plugins.o)(.data+0x3ec):G:/MingW32/src/inet/Ethereal-0.10.1/epan/plugins.c:226: > > undefined reference to `report_read_failure' > > It's a ugly design when a static lib all of a sudden depends on modules using > it (alert_box.c which also requires GTK). I thought epan should be independant > of any GUI.
It is independent of the GUI. It's just not independent of being linked with a program that defines "report_open_failure()" or "report_read_failure()". When linked with Ethereal, "report_open_failure()" and "report_read_failure()" are defined in "alert_box.c", as failures by a dissector to open or read a configuration file (which both the Diameter and "generic ASN.1" dissectors have, namely the Diameter XML file and the "generic ASN.1" file containing the compiled ASN.1 for the protocol it's handling) should be reported by popping up an alert box (so that the user knows that the configuration file couldn't be opened, and that they might have to change it to use a different configuration file pathname, or report the problem to whoever installed Ethereal). When linked with Tethereal, "report_open_failure()" and "report_read_failure()" are defined in "tethereal.c", as failures by a dissector to open or read a configuration file should be printed to the standard error. > I assume the fix is to not call `report_open_failure', but something > else. No. The "something else" that used to be called was "g_message()" or "g_warning()" or something such as that, which sucked, because it meant that, if a dissector in Ethereal had a problem reading a configuration file, crap got spewed to the standard output on UNIX (which means that if Ethereal was run from the GUI, you might not see that output at all, or it might show up in some non-obvious place, or some place not visible at all until you exit the GUI), and spewed to a pop-up console window in Windows. The fix is to have "dftest.c" define its own "report_open_failure()" and "report_read_failure()" routines (which are different from the Tethereal ones, as they report the name "dftest" rather than "tethereal" in the error messages that they print to the standard error). I've checked in that fix. Yes, it could be considered an annoying requirement on the use of the Ethereal library that your program define routines to use when reporting open and read failures. If we allow dissectors to have configuration files (which I think we should), and if we allow them to report to the user, in a way that causes the errors to show up in an obvious place, failures to access configuration files (which I think we should), we probably need to have the program *somehow* supply those routines to the library. _______________________________________________ Ethereal-dev mailing list [EMAIL PROTECTED] http://www.ethereal.com/mailman/listinfo/ethereal-dev
