> > In addition the File->Save menu option causes several GTK error messages
> > to be displayed and a core-dump is produced. I don't think the two
> > problems are realated.
>
> I don't know the source of that, but Craig ran into a number of problems
> with GTK+ on AIX; I forget whether this particular problem was one he
> ran into or not (there was some particularly hideous problem that
> *might* have involved compiling with "xlc_r" rather than "xlc", etc.
> - did you compile with GCC or an IBM compiler?).
No, it was getting confused, apparently, by the fact that we have our
own version of the GTK+ CList code (ours has a change that makes filling
in a CList linear, rather than quadratic, in the ultimate size of the
CList; I've sent the patch to the GTK+ folk, but I don't know if it'll
be in any future GTK+ release.
Most UNIXes appear to have a shared library mechanism based on the SunOS
4.0 one (the one used in systems using ELF, for example, is normally
either the System V Release 4 one or a reimplementation of same), and
that was designed to provide semantics close to those of traditional
UNIX static linking, wherein an application could provide its own
version of a library routine, and the application *and* library routines
it calls will use its version, rather than the version from a library.
AIX's shared library mechanism is, I think, not like that, and it could
get confused by having two sets of CList routines.
Craig caught that one as well; I've added his mail on that to the
"README.aix" file - here's the message in question:
Date: Thu, 11 Nov 1999 23:47:02 -0500
From: Craig Rodrigues <rodrigc@xxxxxxxxxxxx>
To: ethereal-dev@xxxxxxxx
Subject: Re: [ethereal-dev] AIX: gtk problem solved, now an ethereal problem
On Thu, Nov 11, 1999 at 11:50:23AM -0800, Guy Harris wrote:
> > The only differences between gtkclist.c in the gtk distribution and
> > gtkclist.c in the ethereal distribution relate to the ROW_ELEMENT
> > macro. It looks like an optimization for retrieving the GList item
> > when the requested row is the last row in the list.
>
> Yup - as per my other mail, Ethereal does that rather a lot when
> building the CList, and the optimization changes quadratic behavior to
> linear behavior.
>
> > Any ideas why this causes trouble?
>
> Mismatches between the layouts of data structures as declared in the
> "gtk/gtk*.h" files in the Ethereal source tree and the layouts as
> declared in the header files in the GTK+ source (either due to header
> file differences - although the header files appear to be identical to
> the GTK+ 1.2.6 ones - or due to compiler behavior differences)?
I tried stepping things through the debugger, and constantly
hit the same segfault inside gdk_string_width(), line 308 of gdkfont.c
Fails on line: switch(font->type),
where *font is: (type = -1, ascent = -1, descent = -1)
Stack trace:
gdk_string_width(font = 0x7caf01a4, string = "../"), line 308 in "gdkfont.c"
gtk_file_selection_populate(fs = 0x20094468, rel_path = "", try_complete = 0), line 1341 in "gtkfilesel.c"
gtk_file_selection_init(filesel = 0x20094468), line 513 in "gtkfilesel.c"
gtk_type_new(0xc315), line 403 in "gtktypeutils.c"
gtk_file_selection_new(title = "Ethereal: Open Capture File"), line 524 in "gtkfilesel.c"
file_open_cmd_cb(0x200640f4, 0x0), line 79 in "file_dlg.c"
Removing gtkclist.o from libui.a and recompiling removed this problem.
Any ideas? I'm stumped.
--
Craig Rodrigues
http://www.gis.net/~craigr
rodrigc@xxxxxxxxxxxx
so, as noted, removing "gtkclist.o" from the library and recompiling may
clear that problem up.
(We'd rather not just nuke it, given that our change speeds up the
loading of capture files significantly; perhaps we can tweak the config
files to leave it out on AIX.
Long term, we might want to have our own widget for these purposes, with
an API different from that of the GTK+ CList - which thus wouldn't
collide with it - as there are a number of things the CList won't do
that we want.)
