xfig-bin-3.2.4-2 'test' version using shared libXt
Subject line says it all. Please report your positive/negative results to the mailing list. This version depends upon XFree86-bin-4.3.0-5, which includes the new shared Xt DLL. Harold
Shared libXt/Xmu/Xaw/Xaw6 XFree86-bin and XFree86-prog test build
Thanks to Ralf Habacker we have a new test build of the XFree86-bin and XFree86-prog packages: XFree86-bin-4.3.0-5 XFree86-prog-4.3.0-8 These packages use a shared build of the Xt library, which also allowed the Xmu, Xaw, and Xaw6 libraries to be rebuilt as shared. This dropped the XFree86-bin package from 13 MiB to only 4 MiB!!! Please install the above 'test' packages and report your results here. If the reports are good, I will mark this as 'curr' right away. Please send feedback quickly. This was *the* longest awaited cleanup to Cygwin/XFree86 and I would really like to mark this as done as soon as possible. I would also like to submit this patch to XFree86 for inclusion in 4.4.0 if we can make the bug fix deadline. Don't forget to thank Ralf, Harold
Re: cygwin.rules - Enabling shared libXt finally?
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
*
* 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/msg0.html
*/
Re: cygwin.rules - Enabling shared libXt finally?
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
*
* 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/msg0.html
*/
libtest-1.tar.gz2
Description: Binary data
lib_xt.patch
Description: Binary data
Re: (additional info) Can't start gnome-terminal, fatal error
A couple of thoughts... Have you verified that the remote host is actually running a font server? Take a look at /tmp/XWin.log for error messages pertaining to the font path. Try running a local xterm and entering "xset fp+ " instead of using the "-fp" command-line option. From: "Jonathan Primeau" <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: <[EMAIL PROTECTED]> Subject: (additional info) Can't start gnome-terminal, fatal error Date: Wed, 15 Oct 2003 10:10:15 -0400 I have more information related to my problem. I hope that this will make my problem more obvious... When I run gnome-terminal from a standard terminal I get: BEGIN OUTPUT ** (gnome-terminal:161): WARNING **: Cannot load font for XLFD '-bitstream-courier-medium-r-normal--14-*-*-*-*-*-iso8859-1 (gnome-terminal:161): ZVT-WARNING **: Cannot get required fonts from "monospace13" (gnome-terminal:161): ZVT-WARNING **: Use "-*-*-*-*-*-*-13-*-*-*-*-*-*-*" XLFD fontname - some characters may not appear correctly (gnome-terminal:161): ZVT-WARNING **: Use "-*-*-*-*-*-*-0-*-*-*-*-*-*-*" XLFD fontname - some characters may not appear correctly (gnome-terminal:161): ZVT-CRITICAL **: file zvti18n.c: line 831: assertion `new_fontset != NULL' failed (gnome-terminal:161): ZVT-WARNING **: Failed to load any required font, so crash will occur..check X11 font pathes and etc/pangox.alias file ** (gnome-terminal:161): WARNING **: Cannot load font for XLFD '-adobe-helvetica-medium-r-normal--10-*-*-*-*-*-iso8859-1 ** (gnome-terminal:161): WARNING **: Cannot load font for XLFD '-bitstream-courier-medium-r-normal--10-*-*-*-*-*-iso8859-1 (gnome-terminal:161): ZVT-WARNING **: Cannot get required fonts from "monospace10" (gnome-terminal:161): ZVT-WARNING **: Use "-*-*-*-*-*-*-10-*-*-*-*-*-*-*" XLFD fontname - some characters may not appear correctly (gnome-terminal:161): ZVT-WARNING **: Use "-*-*-*-*-*-*-0-*-*-*-*-*-*-*" XLFD fontname - some characters may not appear correctly (gnome-terminal:161): ZVT-CRITICAL **: file zvti18n.c: line 831: assertion `new_fontset != NULL' failed (gnome-terminal:161): ZVT-WARNING **: Failed to load any required font, so crash will occur..check X11 font pathes and etc/pangox.alias file ** (gnome_segv:162): WARNING **: Cannot load font for XLFD '-adobe-helvetica-medium-r-normal--10-*-*-*-*-*-iso8859-1 -- END OUTPUT I guess that the problem comes from "the missing fonts", it says: Failed to load any required font, so crash will occur..check X11 font pathes and etc/pangox.alias file. Is there any way I can fix that? By the way, I use the -fp option for Xwin (Font server). Regards, Jonathan Primeau _ Surf and talk on the phone at the same time with broadband Internet access. Get high-speed for as low as $29.95/month (depending on the local service providers in your area). https://broadband.msn.com
Re: XWin --query
On Wed, 2003-10-15 at 16:49, Sylvain Petreolle wrote: > Just to be sure: are you using the correct option : > XWin -query dmcphost (good) > > not > > XWin --query dmcphost (bad) ? I invoke this via a shell script, and yes the script had a single -. Greg
RE: Two problems with X
Hi José, Check the following FAQ, the answer is obviously there... http://xfree86.cygwin.com/docs/faq/cygwin-xfree-faq.html#q-solaris-fonts The FAQ says: 4.10. Why does Cygwin/XFree86 not display the XDM login prompt on Solaris when I try to open an XDMCP session with a remote Solaris machine? See also Q: 4.11. and Q: 6.16. [David Dawson] For whatever reason, certain versions of Solaris need fonts that are not provided by Cygwin/XFree86; the result is that you may see the Solaris background tile and the hourglass cursor, but the XDM login prompt will never appear. The simplest solution is to point Cygwin/XFree86 at the font server that is usually running on the Solaris machine. You'll need a command line similar to the following to start your XDMCP session and to connect to the Solaris font server: XWin.exe -query solaris_hostname_or_ip_address -fp tcp/solaris_hostname_or_ip_address:7100 Note: The -fp parameter is a general X Server parameter, it is not specific to Cygwin/XFree86; therefore, the -fp is documented in the X Server documentation. For additional information about fonts, see Fonts in XFree86. The standard port number for a font server is 7100, however, you may need to ask your system administrator what the font server port number is if you cannot connect to a font server on port 7100. It is also possible that your Solaris machine is not running a font server, in which case you will need to consult your Solaris documentation for instructions on how to run a font server. Hope this helps, Jonathan Primeau > -Original Message- > From: José Antonio Moreno Zamora [mailto:[EMAIL PROTECTED] > Sent: October 16, 2003 11:28 AM > To: [EMAIL PROTECTED] > Subject: Two problems with X > > > I am trying to connect to Sun WS from an PC with XP and cygwin throug > typical "X -query remote_ws -from local_ws" > I don't obtain any message with error, but the remote login screen doesn't > appear, changing resolution and depth the maximum I have got is to see the > waiting clock from CDE mouse. > When I star X in local mode and connect by telnet exporting display from > remote machine, I can start perfectly the apps, my problem is only with X > -query mode. > I have read a lot of questions and answer about this problem but I can > solve > it. Anyone can help me? > Other question: > To access to a machine with SSH and "X -query" which steps I must do? I > have > seen the option "ssh -X -l user remote_ws", but to obtain whole desktop? > Thanks in advance. > Josan M.
Two problems with X
I am trying to connect to Sun WS from an PC with XP and cygwin throug typical "X -query remote_ws -from local_ws" I dont obtain any message with error, but the remote login screen doesnt appear, changing resolution and depth the maximum I have got is to see the waiting clock from CDE mouse. When I star X in local mode and connect by telnet exporting display from remote machine, I can start perfectly the apps, my problem is only with X -query mode. I have read a lot of questions and answer about this problem but I can solve it. Anyone can help me? Other question: To access to a machine with SSH and "X -query" which steps I must do? I have seen the option "ssh -X -l user remote_ws", but to obtain whole desktop? Thanks in advance. Josan M.
