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.
