On Fri, 1 Aug 2003, Ralf Habacker wrote:
_XInherit:
jmp (*xyz)
where xyz is the address of the image allocation table, in which the address of
the real function address is stored.
So using *(long *)((long)_XInherit+2) in a client dll for comparing gives the
real function address.
Alexander Gottwald wrote:
On Mon, 28 Jul 2003, Ralf Habacker wrote:
I changed the type of _XtInherit to a variable instead of a function.
It compiles but I've not tested it completely.
That was a dead-end too.
With this way we have a symbol which contains the address of the XtInherit
On Mon, 28 Jul 2003, Ralf Habacker wrote:
I changed the type of _XtInherit to a variable instead of a function.
It compiles but I've not tested it completely.
#ifdef SUNSHLIB
/*
* _XtInherit needs to be statically linked since it is compared against as
* well as called.
*/
void
On Tue, 29 Jul 2003, Alexander Gottwald wrote:
+ void (_XtInherit)(void) = __XtInherit;
oops, missed one character. It must be
+ void (*_XtInherit)(void) = __XtInherit;
hope it'n now correct *g*
bye
ago
--
[EMAIL PROTECTED]
http://www.gotti.org ICQ: 126018723
#ifdef SUNSHLIB
/*
* _XtInherit needs to be statically linked since it is compared against as
* well as called.
*/
void _XtInherit()
{
extern void __XtInherit();
__XtInherit();
}
#define _XtInherit __XtInherit
+ #elif defined(CYGWIN)
+ void (_XtInherit)(void) =
On Tue, 29 Jul 2003, Ralf Habacker wrote:
Why ? Does client code access _XtInherit+offset at any place ? Only in that
case the pseudo-reloc stuff is needed.
No. It never uses this indirect access (it would not make sense either since
_XtInherit is a function and (f + 4)() does not make much
On Mon, 28 Jul 2003, Harold L Hunt II wrote:
Nicholas,
I really don't know what to do here. Perhaps some others know what to
do and whether or not this is a good idea.
Would it be easier to update to 4.3.0? Have we already made Xt a shared
lib in 4.3.0?
I've supplied some patches
ago
BTW: there are some design problems with the shared library.
snip
This test is also done in other shared libraries. On linux (and most unices)
there is no problem with this. But on windows the symbol XtInherit in the
other library points to the import table and is different to
On Mon, 28 Jul 2003, Ralf Habacker wrote:
Do you have really tried this ?
yes.
On the assembly level every reference of the above symbol uses the same
symbolname, which is the address of the stub coming from the libxxx.dll.a or any
other import library (or build internally by ld in case of
Harold L Hunt II wrote:
Nicholas,
I really don't know what to do here. Perhaps some others know what to
do and whether or not this is a good idea.
Would it be easier to update to 4.3.0? Have we already made Xt a shared
lib in 4.3.0?
On a side note, has anyone been seeing signs of when
Hi Alexander,
for libXt it uses the direct address. For every other library using
the libXt.dll it uses the address from the stub.
I see, this is another case. Please take a look into xc/lib/xt/Initialize.c and
xc/lib/xt/sharedlib.c which provides such a case for another os. I don't
Ralf Habacker wrote:
Hi Alexander,
for libXt it uses the direct address. For every other library using
the libXt.dll it uses the address from the stub.
I see, this is another case. Please take a look into xc/lib/xt/Initialize.c and
xc/lib/xt/sharedlib.c which provides such a case for
Hi Harold,
It's been awhile... Anyhow, I've been working on a few packages which
use libtool, and thus the reason behind my request. It turns out, using
the new libtool, that one has to go to extreme lengths just to get libXt
to link in, since the new libtool balks at linking true static
Nicholas,
I really don't know what to do here. Perhaps some others know what to
do and whether or not this is a good idea.
Would it be easier to update to 4.3.0? Have we already made Xt a shared
lib in 4.3.0?
On a side note, has anyone been seeing signs of when 4.4.0 is going to
be
: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Michael Bax
Sent: Thursday, November 28, 2002 9:11 AM
To: [EMAIL PROTECTED]
Subject: XFree86 4.2.0 orphans shell on termination
Hi
When closing XWin, I am experiencing relatively frequent
post-termination orphaning (improper clean-up
I haven't tried it since 4.2.0-2
but the new release works fine with the old HP stations as well
as linux. (The releases 4.1.0 and 4.2.0-0 didn't resize/move windows
when dragging the mouse)
And the -nodecoration parameter is great!
Thanks.
- Original Message -
From: Michael [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, April 05, 2002 7:48 AM
Subject: Missing terminfo data in XFree86 4.2.0
Hi
I ran into the following problem with the current XFree86 distribution,
but
could not find any mention of any solution
On Mon, 15 Apr 2002, Michael Reaser wrote:
XWin -query aa.bb.cc.dd -fp tcp/aa.bb.cc.dd:7000
Fatal server error:
XDMCP fatal error: Session failed Session 6 failed for display 0.0.0.0:0:
Cannot open display
you need the -from parameter.
XWin -query aa.bb.cc.dd -from localip (not
I've got a Dell PC running Win98 on which I've installed Cygwin from
http://cygwin.com followed by XFree86 from http://cygwin.com/mirrors
(specifically, archive.progeny.com, and for X I grabbed the binaries
from /cygwin/xfree/binaries/4.2.0). I only brought down the binaries,
as I *really*
Mike,
Try adding -from your_ip_address in your XWin.exe command. Windows may be
reporting a hostname that your sun box doesn't know how to translate back to
an IP. And 0.0.0.0 in that error log seems to go well with that. So then
the full command you'd want to try would be:
XWin
Michael Reaser wrote:
Unfortunately, the PC has an i810, so XWin is giving me fits. It works
fine from another PC without the Intel 810 chipset, and works right
if I just invoke it from the Bash shell using
The chipset shouldn't matter one bit. XWin doesn't use the XFree86 video
about.
- Original Message -
From: Michael [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, April 06, 2002 12:48 AM
Subject: Missing terminfo data in XFree86 4.2.0
Hi
I ran into the following problem with the current XFree86 distribution,
but
could not find any mention of any
Hi
I ran into the following problem with the current XFree86 distribution, but
could not find any mention of any solution here or elsewhere.
SYMPTOMS
* vt102 terminal setting (TERM) in xterm windows instead of xterm
* WARNING: terminal is not fully functional error messages from
Michael,
You already know way more about the problem than I do. I have never seen the
problem described so completely.
Reasoning from what you have said leads me to believe that the packaging
script that we use (same as all of the other XFree86 platforms) may be
misbehaving and accidentally
Pavel,
To Harold: I think this should be included in FAQ (and fixed, if you have
an AIX machine to test it :-)))
This is the first that I have heard of the problem. I need the problem to
be described in more detail before I can add an entry to the FAQ. I need to
know how to reproduce the
[EMAIL PROTECTED]
Subject: RE: Unable to type letters in
login to AIX box using XFree86 4.2.0 on W2K
07.02.2002
I've never seen this problem. Best of luck.
Harold
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Moore, Billiam
Sent: Wednesday, February 06, 2002 4:29 PM
To: '[EMAIL PROTECTED]'
Subject: Unable to type letters in login to AIX box using XFree86
:
cygwin-xfree-owner@Subject: RE: Unable to type letters
in login to AIX box using XFree86 4.2.0 on W2K
cygwin.com
.
They're up on ftp.xfree86.org:/pub/XFree86/4.2.0/binaries/Cygwin
If anyone can test them beside me - that'd be good (mirrors should be
updated soon).
Alan.
XFree86 4.2.0 has been tagged and the binaries are showing up on
ftp.xfree86.org now.
Are we bothering with a distribution as per the normal XFree86 approach?
or is anyone working on distributing XFree86 4.2.0 via the setup.exe
mechanism ?
Alan.
XFree86 4.2.0 has been tagged and the binaries are showing up on
ftp.xfree86.org now.
Are we bothering with a distribution as per the normal XFree86 approach?
or is anyone working on distributing XFree86 4.2.0 via the setup.exe
mechanism ?
Alan.
Alan,
Well, we have to make a standard
On Mon, 21 Jan 2002, Robert Collins wrote:
All that should be needed (as a starting point) for a setup.exe based
distribution (if your current tarballs are rooted at / ) is to
* Create a src package(s) as appropriate. You can have one for all the
binaries (*)
* Rename any hardcoded config
===
- Original Message -
From: Tzafrir Cohen [EMAIL PROTECTED]
Further separations can probably made (separate fonts packages,
separate
documentation packages, etc. Think of all the choices that the install
script gives youon what to install).
I'm talking about getting *something* up
On Mon, 21 Jan 2002, Christopher Faylor wrote:
On Mon, Jan 21, 2002 at 08:51:52AM +0200, Tzafrir Cohen wrote:
On Mon, 21 Jan 2002, Robert Collins wrote:
All that should be needed (as a starting point) for a setup.exe based
distribution (if your current tarballs are rooted at / ) is to
34 matches
Mail list logo