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