Mid Favila <midfav...@sdf.org> writes: > Wanted to add that when Motif (or, at the least, LessTif) programs are > built using tcc, the same problem occurs. Is there anyone else who can > duplicate these findings?
I see the same behaviour -- it's failing in XtQueryGeometry, when it tries to call a widget's query_geometry method. If you set a breakpoint in XtQueryGeometry, when built with gcc, the method pointer widget->core.widget_class->query_geometry is NULL; with tcc, it's _XtInherit. The idea here is that these fields are initialised to _XtInherit, meaning the method should be inherited from the superclass. For each class, RectClassPartInitialize checks whether it's still _XtInherit (XtInheritQueryGeometry is #defined to _XtInherit) and if so gets the pointer from the superclass -- eventually ending up with NULL if there's no definition of it: static void RectClassPartInitialize(register WidgetClass wc) { ... if (roc->rect_class.query_geometry == XtInheritQueryGeometry) { roc->rect_class.query_geometry = super->rect_class.query_geometry; } ... If you set a breakpoint in RectClassPartInitialize and continue until you get to an instance where roc->rect_class.query_encoding isn't NULL, you can see that that fails to work with TCC because the two values are different: (gdb) print _XtInherit $13 = {void (void)} 0x7ffff7b4c870 <_XtInherit> (gdb) print roc->rect_class.query_geometry $16 = (XtGeometryHandler) 0x60aec0 <_XtInherit@plt> Whereas with gcc they're the same (_XtInherit not _XtInherit@plt). At this point this needs someone more familiar with tcc's linking behaviour than me to sort it out -- there are already some horrible-looking hacks in the libXt code to make _XtInherit visible in the right way on various shared library systems. Cheers, -- Adam Sampson <a...@offog.org> <http://offog.org/> _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel