public inbox for cygwin-xfree@sourceware.org
help / color / mirror / Atom feed
* Re: cygwin.rules - Enabling shared libXt finally?
@ 2003-10-21  7:43 Ralf Habacker
  2003-10-21 13:10 ` Harold L Hunt II
  0 siblings, 1 reply; 17+ messages in thread
From: Ralf Habacker @ 2003-10-21  7:43 UTC (permalink / raw)
  To: Cygwin-Xfree@Cygwin. Com

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






^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re: cygwin.rules - Enabling shared libXt finally?
@ 2003-10-17  0:33 Ralf Habacker
  2003-10-17  2:39 ` Harold L Hunt II
  2003-10-17 11:15 ` Alexander Gottwald
  0 siblings, 2 replies; 17+ messages in thread
From: Ralf Habacker @ 2003-10-17  0:33 UTC (permalink / raw)
  To: Cygwin-Xfree@Cygwin. Com

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

^ permalink raw reply	[flat|nested] 17+ messages in thread
* cygwin.rules - Enabling shared libXt finally?
@ 2003-10-01  0:51 Harold L Hunt II
  2003-10-01 12:12 ` Alexander Gottwald
  0 siblings, 1 reply; 17+ messages in thread
From: Harold L Hunt II @ 2003-10-01  0:51 UTC (permalink / raw)
  To: cygx

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


^ permalink raw reply	[flat|nested] 17+ messages in thread
end of thread, other threads:[~2003-10-22 17:16 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-21  7:43 cygwin.rules - Enabling shared libXt finally? Ralf Habacker
2003-10-21 13:10 ` Harold L Hunt II
2003-10-21 18:30   ` AW: " Ralf Habacker
2003-10-22  2:22     ` Charles Wilson
2003-10-22  2:39       ` Harold L Hunt II
2003-10-22 17:16       ` AW: " Ralf Habacker
  -- strict thread matches above, loose matches on Subject: below --
2003-10-17  0:33 Ralf Habacker
2003-10-17  2:39 ` Harold L Hunt II
2003-10-17 11:15 ` Alexander Gottwald
2003-10-01  0:51 Harold L Hunt II
2003-10-01 12:12 ` Alexander Gottwald
2003-10-01 16:35   ` Harold L Hunt II
2003-10-01 19:55     ` Alexander Gottwald
2003-10-01 20:24       ` Harold L Hunt II
2003-10-02 13:31         ` Alexander Gottwald
2003-10-03  3:31           ` Harold L Hunt II
2003-10-03 11:57             ` Alexander Gottwald

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).