This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
Re: cygwin.rules - Enabling shared libXt finally?
- From: Alexander Gottwald <alexander dot gottwald at s1999 dot tu-chemnitz dot de>
- To: cygx <cygwin-xfree at cygwin dot com>
- Date: Wed, 1 Oct 2003 14:12:41 +0200 (MEST)
- Subject: Re: cygwin.rules - Enabling shared libXt finally?
- References: <3F7A24E9.1030900@msu.edu>
- Reply-to: cygwin-xfree at cygwin dot com
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
--
Alexander.Gottwald@s1999.tu-chemnitz.de
http://www.gotti.org ICQ: 126018723