On Tue, 30 Sep 2003, Harold L Hunt II wrote: > Error: Unresolved inheritance operation > > > This error message comes from xc/lib/Xt/Initialize.c/XtInitialize(). > This function has been the root of our problems for some time now. IBM > and Sun have ways to work around similar problems with XtInitialize, > thus the file xc/lib/Xt/sharedlib.c. Also, looking in > xc/config/cf/ibmLib.rules/SharedLibraryTarget shows that they manually > call 'ar' to link sharedlib.o into the equivalent of libXt-6.dll.a. > > I have been able to manually add sharedlib.o to libXt-6.dll.a by running > the following command: > > ar cq libXt-6.dll.a sharedlib.o >
Have you tested this with programs which uses libXt and some widgets from another library? My tests some months ago showed this was not possible. The function _XtInherit from sharedlib.o is linked to different locations in each dll which uses sharedlib.o and the comparisation of the pointers will still fail. > I am looking for some help at finding a pragmatic solution to this. The only solution I've found is redefining _XtInherit to a constant. This will disable the error message "Unresolved inheritance operation" and lead to a crash if the inheritance does not work, but for normal programs the comparisation of _XtInherit across dll will still work. The main problem is: 01: int foo(struct t *x) 02: { 03: while (x->callback == _XtInherit) 04: { 05: x = x->super_class; 06: } 07: x->callback(); 08: } in libXt: 10: struct t x1 = { superclass, _XtInherit }; 11: foo(&x1); in libXaw: 20: struct t x2 = { superclass, _XtInherit }; 21: foo(&x2); The struct x1 contains exactly we want, but x2 expands to x2 = { superclass, _XtInherit_stub }; and _XtInherit_stub is at a different location than _XtInherit. So line 03 will evaluate to this: while (_XtInherit_stub == _XtInherit) // false We can not use code like this __XtInherit() { return _XtInherit(); } struct t x3 = {superclass, __XtInherit() } because the values for x3 must be valid at linktime, but are valid only at runtime. We need: - A symbol which points to the same memory location in all dlls and programs - This symbol must be valid at linktime (there are static structures which use this symbol) With windows the only solution seems to be a constant value. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723