This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [PATCH] Re: pthread


O.k. I now know what's happening...

In the X11-def.cpp we have the following definitions...

 _Xdebug_p=_Xdebug CONSTANT
 _XCreateMutex_fn_p=_XCreateMutex_fn CONSTANT
 _XFreeMutex_fn_p=_XFreeMutex_fn CONSTANT
 _XLockMutex_fn_p=_XLockMutex_fn CONSTANT
 _XUnlockMutex_fn_p=_XUnlockMutex_fn CONSTANT
 _Xglobal_lock_p=_Xglobal_lock CONSTANT

The _Xdebug and _Xglobal_lock definitions are global variables. Whereas
the others are functions.

What's happening is that in libXext it eventually ends up calling the 
_XLockMutex(_Xglobal_lock) function. Then, when threads are not used, which 
is normal in twm's case as it never creates any threads - It should just do 
nothing.

But what happens now is that _Xglobal_lock is used as a check to see
if threads are enabled. If this returns a non-NULL value it assumes that
threads are used. Bang!

_Xglobal_lock 's value is basically being defined as it's pointer in memory
space. Therefore this is where this 0xd1x.... value comes from. It's not
the actual value of _Xglobal_lock.

I'm not a DLL building expert, but we need to fix the pointer/value mismatch.
Whether this can be done with fixing the X11-def.cpp I don't know. There
are some comments in Xlibint.h about defining _XLIBINT_ through the use
of the NeedLibInsideFlag (in cygwin.rules). Whether this can help is another
route.

I need a DLL guru.

Alan.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]