This is the mail archive of the mailing list for the Cygwin XFree86 project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygwin.rules - Enabling shared libXt finally?

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.

--           ICQ: 126018723

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]