Re: cygwin.rules - Enabling shared libXt finally?

Re: cygwin.rules - Enabling shared libXt finally?

[Ralf Habacker]

Harold,

>It looks like you got it nailed to me. I am testing a build right now.
>
I have too additional notes to this patch.

1. Because _Xtinherit is exported as a data symbol, immediate calls to this
function in the manner

...
	_XtInherit();
...

will be relocated wrongly and should be avoided ( I have seen this, but does
not know currently why this happens).

A workaround in case this is absolutly required is to use the following
stuff.

void (*func)(void);

func _blah_blah = XtInherit;

	...
	(*_blah_blah);
	...

2. In the patch there is a symbol named "_y". This should be renamed to a
name, which couldn't be used by regular functions for example
_$Xtinherit_ref or so. The '$' isn't a valid c function name.

Ralf

Re: cygwin.rules - Enabling shared libXt finally?

[Harold L Hunt II]

[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]

Ralf,

Not sure I understand.  What should be changed in the current version of 
the Xt code?

Attached are my curent xc/lib/Xt/[Initialize.c|IntrinsicP.h] files. 
Please send a diff against these if anything should be changed.  Note 
that these are intentionally from the 4.3 branch.

Thanks,

Harold

Ralf Habacker wrote:
> Harold,
> 
> 
>>It looks like you got it nailed to me. I am testing a build right now.
>>
> 
> I have too additional notes to this patch.
> 
> 1. Because _Xtinherit is exported as a data symbol, immediate calls to this
> function in the manner
> 
> ...
> 	_XtInherit();
> ...
> 
> will be relocated wrongly and should be avoided ( I have seen this, but does
> not know currently why this happens).
> 
> A workaround in case this is absolutly required is to use the following
> stuff.
> 
> void (*func)(void);
> 
> func _blah_blah = XtInherit;
> 
> 	...
> 	(*_blah_blah);
> 	...
> 
> 2. In the patch there is a symbol named "_y". This should be renamed to a
> name, which couldn't be used by regular functions for example
> _$Xtinherit_ref or so. The '$' isn't a valid c function name.
> 
> Ralf
> 
> 
> 
> 
> 

[-- Attachment #2: Initialize_and_IntrinsicP.tar.bz2 --]
[-- Type: application/octet-stream, Size: 11822 bytes --]

AW: cygwin.rules - Enabling shared libXt finally?

[Ralf Habacker]

Harold 


> 
> Not sure I understand.  What should be changed in the current version of 
> the Xt code?

only note 1, chaning the label. The second note is only for completeness. 


> Attached are my curent xc/lib/Xt/[Initialize.c|IntrinsicP.h] files. 
> Please send a diff against these if anything should be changed.  Note 
> that these are intentionally from the 4.3 branch.
> 
--- Initialize-old.c       2003-10-21 20:21:18.000000000 +0200
+++ Initialize.c   2003-10-21 20:23:25.000000000 +0200
@@ -236,8 +236,8 @@

 asm (".data\n\
  .globl __XtInherit        \n\
- __XtInherit:      jmp *_$$y \n\
-  _$$y: .long ___XtInherit   \n\
+ __XtInherit:      jmp *__$XtInherit \n\
+ __$XtInherit: .long ___XtInherit   \n\
     .text                 \n");

 #define _XtInherit __XtInherit

Re: AW: cygwin.rules - Enabling shared libXt finally?

[Charles Wilson]

Errm, this isn't going to change the public interface is it?  That is, 
if Harold releases another libXt with this change, would that break the 
recently re-compiled and released lesstif, etc etc?

--
Chuck

Ralf Habacker wrote:

>>Not sure I understand.  What should be changed in the current version of 
>>the Xt code?
> 
> 
> only note 1, chaning the label. The second note is only for completeness. 
> 
> 
> 
>>Attached are my curent xc/lib/Xt/[Initialize.c|IntrinsicP.h] files. 
>>Please send a diff against these if anything should be changed.  Note 
>>that these are intentionally from the 4.3 branch.
>>
> 
> --- Initialize-old.c       2003-10-21 20:21:18.000000000 +0200
> +++ Initialize.c   2003-10-21 20:23:25.000000000 +0200
> @@ -236,8 +236,8 @@
> 
>  asm (".data\n\
>   .globl __XtInherit        \n\
> - __XtInherit:      jmp *_$$y \n\
> -  _$$y: .long ___XtInherit   \n\
> + __XtInherit:      jmp *__$XtInherit \n\
> + __$XtInherit: .long ___XtInherit   \n\
>      .text                 \n");
> 
>  #define _XtInherit __XtInherit

Re: AW: cygwin.rules - Enabling shared libXt finally?

[Harold L Hunt II]

I would be okay with that if it happened.  I am the one that recompiled 
lesstif and I don't think that the maintainers of other Xt-dependent 
apps have recompiled yet.

However, if it isn't a big deal then I will wait until the 4.4.0 release 
to make this change.  4.4.0 should be released around December some time.

Harold

Charles Wilson wrote:

> Errm, this isn't going to change the public interface is it?  That is, 
> if Harold releases another libXt with this change, would that break the 
> recently re-compiled and released lesstif, etc etc?
> 
> -- 
> Chuck
> 
> Ralf Habacker wrote:
> 
>>> Not sure I understand.  What should be changed in the current version 
>>> of the Xt code?
>>
>>
>>
>> only note 1, chaning the label. The second note is only for completeness.
>>
>>
>>> Attached are my curent xc/lib/Xt/[Initialize.c|IntrinsicP.h] files. 
>>> Please send a diff against these if anything should be changed.  Note 
>>> that these are intentionally from the 4.3 branch.
>>>
>>
>> --- Initialize-old.c       2003-10-21 20:21:18.000000000 +0200
>> +++ Initialize.c   2003-10-21 20:23:25.000000000 +0200
>> @@ -236,8 +236,8 @@
>>
>>  asm (".data\n\
>>   .globl __XtInherit        \n\
>> - __XtInherit:      jmp *_$$y \n\
>> -  _$$y: .long ___XtInherit   \n\
>> + __XtInherit:      jmp *__$XtInherit \n\
>> + __$XtInherit: .long ___XtInherit   \n\
>>      .text                 \n");
>>
>>  #define _XtInherit __XtInherit
> 
> 

AW: AW: cygwin.rules - Enabling shared libXt finally?

[Ralf Habacker]

No,

there is no functional changes. I only want to make sure, that no c function
in Intrinsic.c can use the symbol _y (in c 'y'),
so this patch renames it to __$XtInherit, which isn't usable for c
functions.

BTW: I was very in rush while doing the last patch, which may fails to be
applied. The symbol which has to be patched is _y and not _$$y like done in
the previous patch. I've added an updated patch.

Ralf

--- Initialize-old.c       2003-10-21 20:21:18.000000000 +0200
+++ Initialize.c   2003-10-21 20:23:25.000000000 +0200
@@ -236,8 +236,8 @@

 asm (".data\n\
  .globl __XtInherit        \n\
- __XtInherit:      jmp *_y \n\
-  _y: .long ___XtInherit   \n\
+ __XtInherit:      jmp *__$XtInherit \n\
+ __$XtInherit: .long ___XtInherit   \n\
     .text                 \n");

 #define _XtInherit __XtInherit


Ralf

>
> Errm, this isn't going to change the public interface is it?  That is,
> if Harold releases another libXt with this change, would that break the
> recently re-compiled and released lesstif, etc etc?
>
> --
> Chuck
>
> Ralf Habacker wrote:
>
> >>Not sure I understand.  What should be changed in the current
> version of
> >>the Xt code?
> >
> >
> > only note 1, chaning the label. The second note is only for
> completeness.
> >
> >
> >
> >>Attached are my curent xc/lib/Xt/[Initialize.c|IntrinsicP.h] files.
> >>Please send a diff against these if anything should be changed.  Note
> >>that these are intentionally from the 4.3 branch.
> >>
> >
> > --- Initialize-old.c       2003-10-21 20:21:18.000000000 +0200
> > +++ Initialize.c   2003-10-21 20:23:25.000000000 +0200
> > @@ -236,8 +236,8 @@
> >
> >  asm (".data\n\
> >   .globl __XtInherit        \n\
> > - __XtInherit:      jmp *_$$y \n\
> > -  _$$y: .long ___XtInherit   \n\
> > + __XtInherit:      jmp *__$XtInherit \n\
> > + __$XtInherit: .long ___XtInherit   \n\
> >      .text                 \n");
> >
> >  #define _XtInherit __XtInherit
>
>

Re: cygwin.rules - Enabling shared libXt finally?

[Alexander Gottwald]

On Fri, 17 Oct 2003, Ralf Habacker wrote:

> I've found some time to take a look at this problem and it seems as I've got
> a solution, which is documented below.
> Could you please give this a try ?

I had no time to read the patch, but after the latest success messages I have
to thank you for your great work!

bye
	ago
-- 
 Alexander.Gottwald@s1999.tu-chemnitz.de 
 http://www.gotti.org           ICQ: 126018723

Re: cygwin.rules - Enabling shared libXt finally?

[Harold L Hunt II]

Ralf,

It looks like you got it nailed to me.  I am testing a build right now.

Harold

Ralf Habacker wrote:
> Hi all,
> 
> 
>>What we would need is a startup function which replaces pointers to the
>>importlib _XtInherit to the pointer of _XtInherit from the dll.
>>
>>func reloc_addr[] = { .... };
>>unsigned reloc_addr_size = ...;
>>__startup_relocate(void) {
>>   unsigned i;
>>   func real_func = dlsym("cygXt.dll", "_XtInherit");
>>   for (i = 0; i < reloc_addr_size; i++)
>>       *(reloc_addr[i]) = real_func;
>>}
>>
>>This must be added to libXt.dll.a and the linker must fill the reloc_addr
>>array.
> 
> 
> I've found some time to take a look at this problem and it seems as I've got
> a solution, which is documented below.
> Could you please give this a try ?
> 
> cheers
> Ralf
> 
> 
> /*
> /*
>  * The Symbol _XtInherit is used in two different manners. First it could be
> used as a
>  * generric function and second as an absolute address reference, which will
> be used to
>  * check the initialisation process of several other libraries. Because of
> this the symbol
>  * must be accessable by all client dll's and applications.
>  * In unix environments this is no problem, because the used shared
> libraries format (elf)
>  * supports this immediatly.
>  * Under Windows this isn't true, because a functions address in a dll is
> different from
>  * the same function in another dll or applications. The used Portable
> Executable
>  * File adds a code stub to each client to provide the exported symbol name.
> This stub
>  * uses an indirect pointer to get the original symbol address, to which is
> then jumped to,
>  * like this example shows:
>  *
>  * --- client ---                                     --- dll ----
>  *  ...
>  *  call foo
>  *
>  * foo: jmp (*_imp_foo)               ---->           foo: ....
>  *      nop
>  *      nop
>  *
>  * _imp_foo: .long <index of foo in dll export table, is set to the real
> address
>  *                  by the runtime linker>
>  *
>  * Now it is clear why the clients symbol foo isn't the same as in the dll
> and we can think
>  * about how to deal which this two above mentioned requirements, to export
> this symbol to
>  * all clients and to allow calling this symbol as a function.
>  * The solution I've used exports the symbol _XtInherit as data symbol,
> because globale data
>  * symbols are exported to all clients. But how to deal with the second
> requirement, that
>  * this symbol should be used as function ? The Trick is to build a little
> code stub in the
>  * data section in the exact manner as above explained. This is done with
> the assembler code
>  * below.
>  *
>  * References:
>  * msdn          http://msdn.microsoft.com/msdnmag/issues/02/02/PE/PE.asp
>  * cygwin-xfree: http://www.cygwin.com/ml/cygwin-xfree/2003-10/msg00000.html
>  */

Re: cygwin.rules - Enabling shared libXt finally?

[Ralf Habacker]

[-- Attachment #1: Type: text/plain, Size: 2592 bytes --]

Hi all,

>
>What we would need is a startup function which replaces pointers to the
>importlib _XtInherit to the pointer of _XtInherit from the dll.
>
>func reloc_addr[] = { .... };
>unsigned reloc_addr_size = ...;
>__startup_relocate(void) {
>    unsigned i;
>    func real_func = dlsym("cygXt.dll", "_XtInherit");
>    for (i = 0; i < reloc_addr_size; i++)
>        *(reloc_addr[i]) = real_func;
>}
>
>This must be added to libXt.dll.a and the linker must fill the reloc_addr
>array.

I've found some time to take a look at this problem and it seems as I've got
a solution, which is documented below.
Could you please give this a try ?

cheers
Ralf


/*
/*
 * The Symbol _XtInherit is used in two different manners. First it could be
used as a
 * generric function and second as an absolute address reference, which will
be used to
 * check the initialisation process of several other libraries. Because of
this the symbol
 * must be accessable by all client dll's and applications.
 * In unix environments this is no problem, because the used shared
libraries format (elf)
 * supports this immediatly.
 * Under Windows this isn't true, because a functions address in a dll is
different from
 * the same function in another dll or applications. The used Portable
Executable
 * File adds a code stub to each client to provide the exported symbol name.
This stub
 * uses an indirect pointer to get the original symbol address, to which is
then jumped to,
 * like this example shows:
 *
 * --- client ---                                     --- dll ----
 *  ...
 *  call foo
 *
 * foo: jmp (*_imp_foo)               ---->           foo: ....
 *      nop
 *      nop
 *
 * _imp_foo: .long <index of foo in dll export table, is set to the real
address
 *                  by the runtime linker>
 *
 * Now it is clear why the clients symbol foo isn't the same as in the dll
and we can think
 * about how to deal which this two above mentioned requirements, to export
this symbol to
 * all clients and to allow calling this symbol as a function.
 * The solution I've used exports the symbol _XtInherit as data symbol,
because globale data
 * symbols are exported to all clients. But how to deal with the second
requirement, that
 * this symbol should be used as function ? The Trick is to build a little
code stub in the
 * data section in the exact manner as above explained. This is done with
the assembler code
 * below.
 *
 * References:
 * msdn          http://msdn.microsoft.com/msdnmag/issues/02/02/PE/PE.asp
 * cygwin-xfree: http://www.cygwin.com/ml/cygwin-xfree/2003-10/msg00000.html
 */

[-- Attachment #2: libtest-1.tar.gz2 --]
[-- Type: application/octet-stream, Size: 975 bytes --]

[-- Attachment #3: lib_xt.patch --]
[-- Type: application/octet-stream, Size: 3298 bytes --]

Index: lib/Xt/Initialize.c
===================================================================
RCS file: /cvs/xc/lib/Xt/Initialize.c,v
retrieving revision 3.20
diff -u -b -B -r3.20 Initialize.c
--- lib/Xt/Initialize.c	10 Apr 2002 16:20:07 -0000	3.20
+++ lib/Xt/Initialize.c	17 Oct 2003 00:30:54 -0000
@@ -184,6 +184,55 @@
 #define _XtInherit __XtInherit
 #endif
 
+
+/*
+ * The Symbol _XtInherit is used in two different manners. First it could be used as a 
+ * generric function and second as an absolute address reference, which will be used to 
+ * check the initialisation process of several other libraries. Because of this the symbol 
+ * must be accessable by all client dll's and applications. 
+ * In unix environments this is no problem, because the used shared libraries format (elf)
+ * supports this immediatly. 
+ * Under Windows this isn't true, because a functions address in a dll is different from 
+ * the same function in another dll or applications, because the used Portable Executable 
+ * File adds a code stub to each client to provide the exported symbol name. This stub 
+ * uses an indirect pointer to get the original symbol address, which is then jumped to, 
+ * like in this example: 
+ *
+ * --- client ---                                     --- dll ----
+ *  ... 
+ *  call foo 
+ * 
+ * foo: jmp (*_imp_foo)               ---->           foo: .... 
+ *      nop
+ *      nop       
+ * 
+ * _imp_foo: .long <index of foo in dll export table, is set to the real address
+ *                  by the runtime linker>
+ * 
+ * Now it is clear why the clients symbol foo isn't the same as in the dll and we can think 
+ * about how to deal which this two above mentioned requirements, to export this symbol to 
+ * all clients and to allow calling this symbol as a function. 
+ * The solution I've used exports the symbol _XtInherit as data symbol, because global data 
+ * symbols are exported to all clients. But how to deal with the second requirement, that 
+ * this symbol should be used as function.  The Trick is to build a little code stub in the 
+ * data section in the exact manner as above explained. This is don with the assembler code 
+ * below. 
+ * 
+ * References: 
+ * msdn          http://msdn.microsoft.com/msdnmag/issues/02/02/PE/PE.asp
+ * cygwin-xfree: http://www.cygwin.com/ml/cygwin-xfree/2003-10/msg00000.html
+ */
+#ifdef __CYGWIN__
+asm (".data\n\
+ .globl __XtInherit        \n\
+ __XtInherit:      jmp *_y \n\
+  _y: .long ___XtInherit   \n\
+    .text                 \n"); 
+
+
+#define _XtInherit __XtInherit
+#endif
+
 void _XtInherit()
 {
     XtErrorMsg("invalidProcedure","inheritanceProc",XtCXtToolkitError,
Index: lib/Xt/IntrinsicP.h
===================================================================
RCS file: /cvs/xc/lib/Xt/IntrinsicP.h,v
retrieving revision 1.2
diff -u -b -B -r1.2 IntrinsicP.h
--- lib/Xt/IntrinsicP.h	14 Dec 2001 19:56:26 -0000	1.2
+++ lib/Xt/IntrinsicP.h	17 Oct 2003 00:30:56 -0000
@@ -293,11 +293,16 @@
 #endif
 );
 
+#ifndef __CYGWIN__
 extern void _XtInherit(
 #if NeedFunctionPrototypes
     void
 #endif
 );
+#else 
+extern long _XtInherit[];
+#endif 
+
 
 extern void XtCreateWindow(
 #if NeedFunctionPrototypes

Re: cygwin.rules - Enabling shared libXt finally?

[Alexander Gottwald]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1586 bytes --]

Harold L Hunt II wrote:

> Alexander,
>
> I don't understand how your example code relates to the problem at hand.

the structs x1 and x2 represent widget classes from libXt and from eg xclock.
x1 must be linked into the dll and x2 must be linked into the program.

The other problem is the function which compares the callback with _XtInherit.
_XtInherit is bound to an address in the dll, but the callback is bound
to _XtInherit in the program. Both are at different memory locations.

What we would need is a startup function which replaces pointers to the
importlib _XtInherit to the pointer of _XtInherit from the dll.

func reloc_addr[] = { .... };
unsigned reloc_addr_size = ...;
__startup_relocate(void) {
    unsigned i;
    func real_func = dlsym("cygXt.dll", "_XtInherit");
    for (i = 0; i < reloc_addr_size; i++)
        *(reloc_addr[i]) = real_func;
}

This must be added to libXt.dll.a and the linker must fill the reloc_addr
array.

>   I have created a more sophisticated example and I wish that you could
> look at it and modify it if it doesn't currently exhibit the problem
> either.  The code is attached, just 'make' it.
>
> $ ./xtest
> x1.callback: 0x4010e0
> x2.callback: 0x4010e0

Both callbacks are bound to _XtInherit from the program.

I've changed the source to match the problem from libXt. The problem is solved
if the output is
$ ./xtest
x1.callback: 0x1000xxx
x2.callback: 0x4010e0
test(x1): 1
test(x2): 1

Unfortunately it fails at test(x2).

bye
    ago
-- 
 Alexander.Gottwald@informatik.tu-chemnitz.de
 http://www.gotti.org           ICQ: 126018723

[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 1181 bytes --]

Re: cygwin.rules - Enabling shared libXt finally?

[Harold L Hunt II]

[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]

Alexander,

I don't understand how your example code relates to the problem at hand. 
  I have created a more sophisticated example and I wish that you could 
look at it and modify it if it doesn't currently exhibit the problem 
either.  The code is attached, just 'make' it.

Of course, anyone else is free to look at the code and comment.

The code compiles fine for me and gives the following results:

$ ./xtest
x1.callback: 0x4010e0
x2.callback: 0x4010e0


$ ./xtest2
x1.callback: 0x4010f0
x2.callback: 0x4010f0


You can uncomment the DEFINES in Makefile to define SHAREDCODE or not... 
which changes the way that _XtInherit is defined in sharedlib.c.

I am not really sure what it is I am trying to do here.  Making this 
example feature complete will really help me to understand.

Thanks,

Harold

Alexander Gottwald wrote:

> Harold L Hunt II wrote:
> 
> 
>>>gcc -shared -o x1.dll x1.c xtinherit.c
>>
>>                  ^^^^^^      ^^^^^^^^^^^
>>
>>That is the crux of my whole argument, and I believe it is what Alan was
>>trying to tell me to do.  You do *not* link xtinherit.c/o into x1.dll.
>>Instead, only for demonstration purposes, you can link it directly into
>>any executables that link to x1.dll.
>>
>>What is your response to that?
> 
> 
> i686-pc-cygwin32-gcc -shared -o x1.dll x1.c
> /tmp/ccE9Szng.o(.data+0x0):x1.c: undefined reference to `__XtInherit'
> 
> bye
>     ago

[-- Attachment #2: libtest.tar.bz2 --]
[-- Type: application/x-tar, Size: 1063 bytes --]

Re: cygwin.rules - Enabling shared libXt finally?

[Alexander Gottwald]

Harold L Hunt II wrote:

> > gcc -shared -o x1.dll x1.c xtinherit.c
>                   ^^^^^^      ^^^^^^^^^^^
>
> That is the crux of my whole argument, and I believe it is what Alan was
> trying to tell me to do.  You do *not* link xtinherit.c/o into x1.dll.
> Instead, only for demonstration purposes, you can link it directly into
> any executables that link to x1.dll.
>
> What is your response to that?

i686-pc-cygwin32-gcc -shared -o x1.dll x1.c
/tmp/ccE9Szng.o(.data+0x0):x1.c: undefined reference to `__XtInherit'

bye
    ago
-- 
 Alexander.Gottwald@informatik.tu-chemnitz.de
 http://www.gotti.org           ICQ: 126018723

Re: cygwin.rules - Enabling shared libXt finally?

[Harold L Hunt II]

Alexander Gottwald wrote:

> On Wed, 1 Oct 2003, Harold L Hunt II wrote:
> 
> 
>>Alexander Gottwald wrote:
>>
>>>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.
> 
> 
> The location of _XtInherit still differs in dll and program. 
> 
> 
>>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.
> 
> 
> no. The structures of the dll are initialized with dll_base + x and the 
> structures from the program are inititalized with program_base + y. Even
> if we find a way to have x == y, the symbols still differ because the 
> dll is placed on a different place than the program.
> 
> Simple testprogram:
> 
> --x.h
> typedef void (*func)(void);
> extern void _XtInherit(void);
> typedef struct { func callback; } x;
> extern x x1, x2;
> --xtinherit.c
> #include "x.h"
> void _XtInherit(void) {
> }
> --x1.c
> #include "x.h"
> x x1 = { _XtInherit };
> --x2.c
> #include "x.h"
> x x2 = { _XtInherit };
> --xtest.c
> #include "x.h"
> #include <stdio.h>
> 
> int main(void) {
>     printf("x1.callback: %p\n", x1.callback);
>     printf("x2.callback: %p\n", x2.callback);
>     return 0;
> }
> --build.sh
> gcc -shared -o x1.dll x1.c xtinherit.c
                  ^^^^^^      ^^^^^^^^^^^

That is the crux of my whole argument, and I believe it is what Alan was 
trying to tell me to do.  You do *not* link xtinherit.c/o into x1.dll. 
Instead, only for demonstration purposes, you can link it directly into 
any executables that link to x1.dll.

What is your response to that?

Harold



> gcc -o xtest.exe xtest.c x2.c xtinherit.c x1.dll
> gcc -o xtest2.exe xtest.c x2.c x1.dll
> --output xtest.exe
> x1.callback: 0x10001010  
> x2.callback: 0x4010d0
> --output xtest2.exe
> x1.callback: 0x10001010
> x2.callback: 0x401750
> 
> bye
> 	ago

Re: cygwin.rules - Enabling shared libXt finally?

[Alexander Gottwald]

On Wed, 1 Oct 2003, Harold L Hunt II wrote:

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

The location of _XtInherit still differs in dll and program. 

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

no. The structures of the dll are initialized with dll_base + x and the 
structures from the program are inititalized with program_base + y. Even
if we find a way to have x == y, the symbols still differ because the 
dll is placed on a different place than the program.

Simple testprogram:

--x.h
typedef void (*func)(void);
extern void _XtInherit(void);
typedef struct { func callback; } x;
extern x x1, x2;
--xtinherit.c
#include "x.h"
void _XtInherit(void) {
}
--x1.c
#include "x.h"
x x1 = { _XtInherit };
--x2.c
#include "x.h"
x x2 = { _XtInherit };
--xtest.c
#include "x.h"
#include <stdio.h>

int main(void) {
    printf("x1.callback: %p\n", x1.callback);
    printf("x2.callback: %p\n", x2.callback);
    return 0;
}
--build.sh
gcc -shared -o x1.dll x1.c xtinherit.c
gcc -o xtest.exe xtest.c x2.c xtinherit.c x1.dll
gcc -o xtest2.exe xtest.c x2.c x1.dll
--output xtest.exe
x1.callback: 0x10001010  
x2.callback: 0x4010d0
--output xtest2.exe
x1.callback: 0x10001010
x2.callback: 0x401750

bye
	ago
-- 
 Alexander.Gottwald@s1999.tu-chemnitz.de 
 http://www.gotti.org           ICQ: 126018723

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

Re: cygwin.rules - Enabling shared libXt finally?

[Alexander Gottwald]

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

cygwin.rules - Enabling shared libXt finally?

[Harold L Hunt II]

With the release of Cygwin 1.5.x and newer versions of binutils, can we 
finally make libXt a shared library?

I have been working with Alan to try to build a shared version of the 
library, but I keep getting the following message upon startup of 
Xt-dependent apps:

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


I am looking for some help at finding a pragmatic solution to this.

First of all, I want to take a survey of whether anyone thinks we 
actually have the necessary support in binutils to do this yet. 
Secondly, I want to know if anyone can help me to figure out how to do this.

Note that the first thing to do is edit xc/config/cf/cygwin.rules and 
change the Xt, Xaw, Xmu, etc. shared lib flags from NO to YES.  After 
that, you can add $(UNSHAREDOBJS) to your 
cygwin.rules/SharedLibraryTarget dependencies.  This will cause 
xc/lib/Xt/sharedlib.o to be built automatically, but it will not be 
linked by default.

Awaiting some input,

Harold