cygwin.rules - Enabling shared libXt finally?

[Harold L Hunt II]

Alexander Gottwald wrote:
> 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?

Yeah, that is what I was saying above.  I built a shared version, made 
some changes, and rebuilt some clients (xman.exe, xcalc.exe, etc.), but 
they keep giving the unresolved inheritence error as above.

> 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.

Actually, if you look at 
xc/config/cf/ibmLib.rules/SharedLibraryTarget(), you see that 
sharedlib.o (which is contained in $(UNSHAREDOBJS)) is linked directly 
into the import library, not into the shared library.  The idea is that 
each application linked against libXt should end up with one copy of the 
sharedlib.o code.  Thus, comparisons against _XtInherit will work just 
fine within one application, which is the only case that we are 
concerned with.

> 
> 
>>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

Not really.  We just need a symbol that points to the same location 
within one executable --- one that all libraries linked to the 
executable can see.  This one symbol needs to have a linktime valid 
address.  This seems totally possible if a modified sharedlib.o is 
either linked directly into each client (for testing purposes only) or 
if we manually add sharedlib.o to the import library for Xt (not to the 
DLL itself).

> - This symbol must be valid at linktime (there are static structures which
>   use this symbol)

See above, I think this is possible.


Thanks for the input,

Harold