This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
Re: [XFree86-4.2.0] Now that we have an improved ld, please makelibXt a shared library.
- From: Alexander Gottwald <alexander dot gottwald at s1999 dot tu-chemnitz dot de>
- To: cygwin-xfree at cygwin dot com
- Date: Mon, 28 Jul 2003 11:38:13 +0200 (MEST)
- Subject: Re: [XFree86-4.2.0] Now that we have an improved ld, please makelibXt a shared library.
- References: <bg1kkb$din$1@main.gmane.org> <3F24B095.6030707@msu.edu>
- Reply-to: cygwin-xfree at cygwin dot com
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 that enable building of a shared libXt.
We've postponed the switch to the shared library since it required new
binutils and some other new packages. Maybe these packages are now wide
spread and we can release the shared version. (Including a change to cygwin
1.5.0, versioned dll names, IPC?)
bye
ago
BTW: there are some design problems with the shared library.
There is a function XtInherit which is used as a kind of NULL value.
void XtInherit(void) {};
struct Str {
void (*func)(void);
};
Str x;
x.func = XtInherit;
And on some places they test if x.func is set:
if (x.func != XtInherit) {
...
}
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 the pointer
stored in the struct. The comparisation will not work.
I've created a work around where I store a fixed value instead of the pointer
to XtInherit. But this will cause a segfault if somehow someone tries to call
x.func().
bye
ago