Started playing with Wineserver on mingw/cygwin again
well I made it serial.c before I had to run to work. I'm having good luck getting alot of the objects to compile so far I've only had to kill file.c, ptrace.c, request.c and select.c. Getting this to build and run on Windows is going to be a bitch =) gettimeofday, fork and all of fd and networking is going to be the hard part. I've started a tempory header to see what will need to be implemented in libwine if we want to get wineserver up and running on Windows without cygwin. Cygwin still really needed get/setthreadcontext (hint, hint) Thanks Steven /* I kill'd file.c, ptrace.c, request.c, select.c * * get/set thread context still needs to be done for Mingw and Cygwin * * main.c needs a lot of work */ /* object.h and async.h */ struct timeval{ int tv_sec; int tv_usec; }; /* debugger.c */ #define SIGTRAP NULL /* file.c - doesnt work */ #define O_NONBLOCK 0 #define POLLIN 0 #define POLLOUT 0 #define POLLIN 0 #define POLLOUT 0 /* main.c */ #define SIGPIPE NULL #define SIGHUP NULL #define SIGQUIT NULL /* named_pipe.c */ #define PF_UNIX NULL #define SOCK_STREAM NULL /* object.c */ #define POLLERR 0 #define POLLHUP 0 __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Steven Edwards wrote:
well I made it serial.c before I had to run to work. I'm having good luck getting alot of the objects to compile so far I've only had to kill file.c, ptrace.c, request.c and select.c. Getting this to build and run on Windows is going to be a bitch =) gettimeofday, fork and all of fd and networking is going to be the hard part. I've started a tempory header to see what will need to be implemented in libwine if we want to get wineserver up and running on Windows without cygwin.
Cygwin still really needed get/setthreadcontext (hint, hint)
OK, as far as I understand it this means we need to implement a cygwin version of get_thread_context and set_thread_context in server/context_i386.c. What I'm not sure about is, when running wineserver on cygwin, would the threads created in Wine have a one-to-one correspondence to Windows threads? Or would they be strange, different, unix-style threads which cygwin then maps down to Windows threads? Could we go straight down to the underlying win32 api and do a GetThreadContext there? Is that cheating? David
OK, as far as I understand it this means we need to implement a cygwin version of get_thread_context and set_thread_context in server/context_i386.c. What I'm not sure about is, when running wineserver on cygwin, would the threads created in Wine have a one-to-one correspondence to Windows threads? Or would they be strange, different, unix-style threads which cygwin then maps down to Windows threads? Could we go straight down to the underlying win32 api and do a GetThreadContext there? Is that cheating?
David
I'm not sure if it is cheating or not. I tried to write a little wrapper that just forwards our implementation to the Windows kernel32 GetThreadContext a while back but in the current Wine Windows.h you can't include it internaly so I never did much more with it. Everyone already knows I dont write good code so I have never tried to do more with it untill now. Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
On February 1, 2003 02:10 am, David Fraser wrote:
Could we go straight down to the underlying win32 api and do a GetThreadContext there? Is that cheating?
I don't know the Cygwin threading model, but calling the real [GS]etThreadContext is a good first order approximation. If interested in this task, I'd bring it up on the Cygwin mailing list... -- Dimi.
Dimitrie O. Paun wrote:
On February 1, 2003 02:10 am, David Fraser wrote:
Could we go straight down to the underlying win32 api and do a GetThreadContext there? Is that cheating?
I don't know the Cygwin threading model, but calling the real [GS]etThreadContext is a good first order approximation. If interested in this task, I'd bring it up on the Cygwin mailing list...
Just as a start, I tried this ... compiles fine but don't know how to test it ... Does this look right? (just done for get_thread_context) David Index: server/context_i386.c =================================================================== RCS file: /home/wine/wine/server/context_i386.c,v retrieving revision 1.24 diff -u -r1.24 context_i386.c --- server/context_i386.c 8 Nov 2002 18:55:31 -0000 1.24 +++ server/context_i386.c 4 Feb 2003 17:53:57 -0000 @@ -76,7 +76,31 @@ #define PTRACE_SETDBREGS PT_SETDBREGS #endif -#ifdef linux +#if defined(__CYGWIN__) + +/* need to access handles... */ +#include "handle.h" + +/* retrieve a thread context */ +static void get_thread_context( struct thread *thread, unsigned int flags, CONTEXT *context ) +{ + /* get a handle to the thread with all access, not inheritable */ + HANDLE hThread = alloc_handle(thread->process, thread, THREAD_ALL_ACCESS, 0); + /* cheat and call underlying Windows GetThreadContext directly... */ + BOOL success = GetThreadContext(hThread, context); + /* now release the handle... */ + close_handle(thread->process, hThread, NULL); +} + + +/* set a thread context */ +static void set_thread_context( struct thread *thread, unsigned int flags, const CONTEXT *context ) +{ + /* FIXME: implement this */ + file_set_error(); +} + +#elif defined(linux) #ifdef HAVE_SYS_USER_H # include <sys/user.h> #endif
David Fraser wrote:
Dimitrie O. Paun wrote:
On February 1, 2003 02:10 am, David Fraser wrote:
Could we go straight down to the underlying win32 api and do a GetThreadContext there? Is that cheating?
I don't know the Cygwin threading model, but calling the real [GS]etThreadContext is a good first order approximation. If interested in this task, I'd bring it up on the Cygwin mailing list...
Just as a start, I tried this ... compiles fine but don't know how to test it ... Does this look right? (just done for get_thread_context)
David
OK, having actually thought I can see that this is not going to work. Basically in order to do a GetThreadContext we need to get a handle to the underlying Windows thread... what I was doing here was asking the Wine server for a handle to the thread, then passing that to Windows. I've now tried to look at the code to see what exactly the correspondence between threads on Wine running on cygwin to underlying native threads would be. (I then discovered I'd already done this previously: http://www.winehq.com/hypermail/wine-devel/2002/11/1533.html) I'm fairly ignorant about the code so I'd appreciate any feedback on my comments here. From examining the code it looks to me like in Wine, "Windows" threads are created in scheduler/sysdeps.c:SYSDEPS_SpawnThread, where there is a call to clone which creates the thread. "Windows" threads are initialized by sending request in the client code: In scheduler/client.c, CLIENT_InitThread uses getpid() to determine the unix_pid in req which then gets set on the thread in server/thread.c:init_thread. Under cygwin, there is no clone call as far as I can make out ... there is pthreads support and there is hackish support for fork. Can Wine use pthreads to implement its threading? David
On February 5, 2003 03:36 am, David Fraser wrote:
Under cygwin, there is no clone call as far as I can make out ... there is pthreads support and there is hackish support for fork.
Do threads in Cygwin's pthreads map one-to-one to Windows threads?
Can Wine use pthreads to implement its threading?
I'm curious about that myself, Alexandre was saying that we have to do it, to accommodate the new glibc threading changes. I'd say this is a top issue since I expect the new glibc to make it's way into distributions fairly soon (maybe by RedHat 9.0), and which point we'll be in a lot of trouble. What's the thinking on this, currently? -- Dimi.
On Wed, Feb 05, 2003 at 09:00:27AM -0500, Dimitrie O. Paun wrote:
On February 5, 2003 03:36 am, David Fraser wrote:
Under cygwin, there is no clone call as far as I can make out ... there is pthreads support and there is hackish support for fork.
Do threads in Cygwin's pthreads map one-to-one to Windows threads?
Can Wine use pthreads to implement its threading?
I'm curious about that myself, Alexandre was saying that we have to do it, to accommodate the new glibc threading changes. I'd say this is a top issue since I expect the new glibc to make it's way into distributions fairly soon (maybe by RedHat 9.0), and which point we'll be in a lot of trouble. What's the thinking on this, currently?
No, Redhat Phoebe is affected already (is that 8.1?). Shipping soon. Ciao, marcus
Apparently that's the case yes. So, I guess the real question now is, how fast can Wine be ported to the glibc threading model. Assuming it can be. On Wed, 2003-02-05 at 14:54, Dimitrie O. Paun wrote:
On Wed, 5 Feb 2003, Marcus Meissner wrote:
No, Redhat Phoebe is affected already (is that 8.1?). Shipping soon.
Duh! So what will it happen -- Wine will not run on RH 8.1?!? -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center
Mike Hearn a écrit:
Apparently that's the case yes. So, I guess the real question now is, how fast can Wine be ported to the glibc threading model. Assuming it can be.
On Wed, 2003-02-05 at 14:54, Dimitrie O. Paun wrote:
On Wed, 5 Feb 2003, Marcus Meissner wrote:
No, Redhat Phoebe is affected already (is that 8.1?). Shipping soon.
Duh! So what will it happen -- Wine will not run on RH 8.1?!?
Phoebe (the current RH beta, labeled 8.0.93) lists glibc-2.3.1, and doesn't include any wine package. Rawhide (the bleeding edge version of RH) doesn't have any wine package either. FWIW, Debian already ships (in unstable) glibc-2.3.1. Somebody using it can tell us if it breaks Wine for them? Vincent
There were some rumblings on the crossover users list, so I think it's safe to assume Phoebe is a no go On Wed, 2003-02-05 at 16:35, Vincent Béron wrote:
Mike Hearn a écrit:
Apparently that's the case yes. So, I guess the real question now is, how fast can Wine be ported to the glibc threading model. Assuming it can be.
On Wed, 2003-02-05 at 14:54, Dimitrie O. Paun wrote:
On Wed, 5 Feb 2003, Marcus Meissner wrote:
No, Redhat Phoebe is affected already (is that 8.1?). Shipping soon.
Duh! So what will it happen -- Wine will not run on RH 8.1?!?
Phoebe (the current RH beta, labeled 8.0.93) lists glibc-2.3.1, and doesn't include any wine package. Rawhide (the bleeding edge version of RH) doesn't have any wine package either.
FWIW, Debian already ships (in unstable) glibc-2.3.1. Somebody using it can tell us if it breaks Wine for them?
Vincent
Phoebe (the current RH beta, labeled 8.0.93) lists glibc-2.3.1, and doesn't include any wine package. Rawhide (the bleeding edge version of RH) doesn't have any wine package either.
FWIW, Debian already ships (in unstable) glibc-2.3.1. Somebody using it can tell us if it breaks Wine for them?
I don't run Debian unstable, but I /do/ run Gentoo. My glibc version is 2.3.1 (-r2, for those of you who are running Gentoo); WINE works perfectly fine for me. I use it almost daily to play games, etc. Phil
On Wed, Feb 05, 2003 at 01:10:10PM -0600, Phil Bordelon wrote:
Phoebe (the current RH beta, labeled 8.0.93) lists glibc-2.3.1, and doesn't include any wine package. Rawhide (the bleeding edge version of RH) doesn't have any wine package either.
FWIW, Debian already ships (in unstable) glibc-2.3.1. Somebody using it can tell us if it breaks Wine for them?
I don't run Debian unstable, but I /do/ run Gentoo. My glibc version is 2.3.1 (-r2, for those of you who are running Gentoo); WINE works perfectly fine for me. I use it almost daily to play games, etc. AFAIK you need also an nptl enabled kernel to enable the new threading model. This would be an actual 2.5 kernel or a 2.4 kernel from Red Hat's Rawhide or Phoebe.
bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart
On Wednesday 05 February 2003 01:10 pm, Phil Bordelon wrote:
Phoebe (the current RH beta, labeled 8.0.93) lists glibc-2.3.1, and doesn't include any wine package. Rawhide (the bleeding edge version of RH) doesn't have any wine package either.
FWIW, Debian already ships (in unstable) glibc-2.3.1. Somebody using it can tell us if it breaks Wine for them?
I don't run Debian unstable, but I /do/ run Gentoo. My glibc version is 2.3.1 (-r2, for those of you who are running Gentoo); WINE works perfectly fine for me. I use it almost daily to play games, etc.
Phil
My gentoo works fine, too, with 2.4.21-ac1. They apply some patches: bad-penguin 2.3.1 # pwd /usr/portage/sys-libs/glibc/files/2.3.1 bad-penguin 2.3.1 # ls -l total 104 -rw-r--r-- 1 root root 1468 Nov 7 09:21 glibc-2.3.1-ctype-compat-v2.patch -rw-r--r-- 1 root root 2823 Jan 14 18:36 glibc-2.3.1-ctype-compat-v3.patch -rw-r--r-- 1 root root 728 Oct 25 19:53 glibc-2.3.1-ctype-compat.patch -rw-r--r-- 1 root root 1246 Jan 14 18:36 glibc-2.3.1-elf-machine-rela-mips.patch -rw-r--r-- 1 root root 633 Jan 14 18:36 glibc-2.3.1-exit-syscall-mips.patch -rw-r--r-- 1 root root 433 Jan 14 18:36 glibc-2.3.1-fpu-cw-mips.patch -rw-r--r-- 1 root root 7753 Jan 23 16:23 glibc-2.3.1-inline-syscall-mips.patch -rw-r--r-- 1 root root 1053 Nov 16 12:28 glibc-2.3.1-libc_wait-compat.patch -rw-r--r-- 1 root root 5222 Jan 14 18:36 glibc-2.3.1-libgcc-compat-mips.patch -rw-r--r-- 1 root root 396 Jan 14 18:36 glibc-2.3.1-librt-mips.patch -rw-r--r-- 1 root root 8666 Jan 14 18:36 glibc-2.3.1-locale.patch -rw-r--r-- 1 root root 5005 Nov 17 06:15 glibc-2.3.1-prelinkfix.patch -rw-r--r-- 1 root root 751 Nov 7 09:21 glibc-2.3.1-stack_end-compat.patch -rw-r--r-- 1 root root 446 Jan 14 18:36 glibc-2.3.1-tst-rndseek-mips.patch -rw-r--r-- 1 root root 27618 Jan 14 18:36 glibc-2.3.1-ulps-mips.patch One note: it's very easy for us gentoo'ers to recompile our glibc and test against it, and then to revert back. (Presumably, adding patches to this directory (or maybe the ebuild) and re-emerging is all it would take). That makes us perfect guinea pigs, so, if anyone has something they want tested... As for the courtesy issue: I wouldn't get too worked up about this. Note that wine seems to be the only program using glibc in this way. In all candor, it seems to me (note that this is from the perspective of someone who really doesn't even understand the problem yet) that we were not really supposed to use TLS in this way, and that we should be willing to "fix" our approach, difficult as this may be, rather than complain that they should have warned us. We have our warning.... let's fix the damn thing! That being stated, I think a lot of us non-guru's would appreciate it if someone who has a good handle on this problem could try to outline what our options are? It seems, so far, that we have: 1) Get glibc to change (not too likely) 2) Change the kernel, a la Igno Molnar, 3) Change wine 3a) Use pthreads. 3b) ? 4) ? Again, speaking from a position of considerable ignorance, the pthreads thing has a certain appeal, since the lack of pthreads support in wine seems to be causing problems for other projects... so, who can speak to this possiblity? How difficult is it? How drastically would this change wine's overall design? I think we should tentatively choose a path and "just go for it." If we hit a brick wall, then we can address that at the time -- Alexandre, I think, can be trusted not to put anything in CVS that isn't good ;) Maybe all we need is a clearer map of where we are going with this and what needs to be done, so that we can farm out the work to the appropriate people? Sorry if that's a meaningless pep-talk... maybe instead of typing at you guys I should be reading source code eh? But there you have it. -- gmt p.s., I'll be out of town today and tomorrow. See you all soon!
Dimitrie O. Paun wrote:
On Wed, 5 Feb 2003, Marcus Meissner wrote:
No, Redhat Phoebe is affected already (is that 8.1?). Shipping soon.
Duh! So what will it happen -- Wine will not run on RH 8.1?!?
That's right. This is a top priority worry of mine. It's so bad that I was considering working on it myself, since nobody else seemed to be worried. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
* Dan Kegel (dank(a)kegel.com) wrote:
Dimitrie O. Paun wrote:
On Wed, 5 Feb 2003, Marcus Meissner wrote:
No, Redhat Phoebe is affected already (is that 8.1?). Shipping soon.
Duh! So what will it happen -- Wine will not run on RH 8.1?!?
That's right. This is a top priority worry of mine. It's so bad that I was considering working on it myself, since nobody else seemed to be worried.
I am worried also and, though I have yet to throw myself into wine internals even *once*, I am also willing to give whatever I can to this effort. I use Wine from time to time, but more than anything else I have been watching its progress from the sidelines for potential future uses and also a "feeling" of how it is a key OSS project worth keeping an eye on. What disturbs me most about this pthread/glibc issue is the (apparent) impunity with which the glibc maintainer has just barged ahead with this disruptive change with (again, apparently) little concern for the fallout it would cause. Wine is important to anyone who cares about the ongoing political dynamics of the open source software cause, and one could be forgiven for assuming the glibc folks themselves would fall into this category?! IMHO the glibc maintainer should have been circling wagons before this problem came to a head - and wine is certainly one of the wagons to get priority circling.[1] Now if I've been wrong and the fault here is on the wine development project (or Codeweavers, Transgaming, etc) for not planning sufficiently ahead, then please point me to archives of the appropriate threads (pun half-intended) and the glibc maintainer can have my apologies in advance. Dan - if you want to co-ordinate this and are willing to accommodate my coming to grips with the wine specifics (have you ever contemplated a less precise request for help? :-), please get in touch via private email and I'll do what I can to contribute, investigate, research, hack, whatever. Regards, Geoff [1] For that matter, has anyone attempted to pull this person into the wine discussion to help flesh this out and find the optimal way forward? Surely any self-respecting (L)GPLer would hate to see a major tool for open source advancement getting hurt over this without so much as some constructive help? -- Geoff Thorpe geoff(a)geoffthorpe.net http://www.geoffthorpe.net/
On Wed, 5 Feb 2003, Geoff Thorpe wrote:
[1] For that matter, has anyone attempted to pull this person into the wine discussion to help flesh this out and find the optimal way forward? Surely any self-respecting (L)GPLer would hate to see a major tool for open source advancement getting hurt over this without so much as some constructive help?
This is an interesting question. I know Ingo Molnar has been (one of) the main developer working on the glibc threading stuff, and I also know he used to follow the Wine project. I am sure he's not indifferent to our fate, and being so deeply involved with the glibc changes, he's probably an invaluable resource. Unfortunately, I'm not sure he's even aware of the problem -- has anyone contacted him? Anyone want to do so? (Dan? :)) -- Dimi.
On Wed, Feb 05, 2003 at 01:47:54PM -0500, Dimitrie O. Paun wrote:
On Wed, 5 Feb 2003, Geoff Thorpe wrote:
[1] For that matter, has anyone attempted to pull this person into the wine discussion to help flesh this out and find the optimal way forward? Surely any self-respecting (L)GPLer would hate to see a major tool for open source advancement getting hurt over this without so much as some constructive help?
This is an interesting question. I know Ingo Molnar has been (one of) the As far as I know he probably reads wine-devel too.
main developer working on the glibc threading stuff, and I also know he He did the kernel stuff, the glibc part was done by Ulrich Drepper.
used to follow the Wine project. I am sure he's not indifferent to our He even follows rewind .
fate, and being so deeply involved with the glibc changes, he's probably an invaluable resource. Unfortunately, I'm not sure he's even aware of the problem -- has anyone contacted him? Anyone want to do so? (Dan? :)) I'll write him an email.
bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart
Hello, i hate to reply to myself but here is Ingo's answer: | could you try: | | export LD_ASSUME_KERNEL=2.2.5 | | prior starting up Wine, does this fix the problem for you? | | I'm talking to Alexandre wrt. the threading rewrite - it will be | problematic (release-management wise) but is unavoidable. I'm building now wine on Phoebe and test if the workaround will work, but it will take some time cause the box is only a PII-450. bye michael On Wed, Feb 05, 2003 at 08:14:19PM +0100, Michael Stefaniuc wrote:
On Wed, Feb 05, 2003 at 01:47:54PM -0500, Dimitrie O. Paun wrote:
On Wed, 5 Feb 2003, Geoff Thorpe wrote:
[1] For that matter, has anyone attempted to pull this person into the wine discussion to help flesh this out and find the optimal way forward? Surely any self-respecting (L)GPLer would hate to see a major tool for open source advancement getting hurt over this without so much as some constructive help?
This is an interesting question. I know Ingo Molnar has been (one of) the As far as I know he probably reads wine-devel too.
main developer working on the glibc threading stuff, and I also know he He did the kernel stuff, the glibc part was done by Ulrich Drepper.
used to follow the Wine project. I am sure he's not indifferent to our He even follows rewind .
fate, and being so deeply involved with the glibc changes, he's probably an invaluable resource. Unfortunately, I'm not sure he's even aware of the problem -- has anyone contacted him? Anyone want to do so? (Dan? :)) I'll write him an email.
bye michael
-- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart
On Wed, 5 Feb 2003, Michael Stefaniuc wrote:
Hello,
i hate to reply to myself but here is Ingo's answer: | could you try: | | export LD_ASSUME_KERNEL=2.2.5 | | prior starting up Wine, does this fix the problem for you?
According to reports on the CrossOver mailing lists this works on Phoebe 1 but does not work anymore on Phoebe 2. Also it causes Wine to fail on some platforms like SuSE 8.1 so it should not be blindly set. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: the choice of a GNU generation
On Wed, Feb 05, 2003 at 01:47:46PM -0800, Francois Gouget wrote:
On Wed, 5 Feb 2003, Michael Stefaniuc wrote:
Hello,
i hate to reply to myself but here is Ingo's answer: | could you try: | | export LD_ASSUME_KERNEL=2.2.5 | | prior starting up Wine, does this fix the problem for you?
According to reports on the CrossOver mailing lists this works on Phoebe 1 but does not work anymore on Phoebe 2. Phoebe 2 had kernel-2.4.20-2.21 and that one had some problems with signals. Usable for wine are kernels starting with kernel-2.4.20-2.30. The actual kernel in rawhide is 2.4.20-2.34; i'll test tomorrow wine on Phoebe 2 with the actual kernel.
Also it causes Wine to fail on some platforms like SuSE 8.1 so it should not be blindly set. Yet another configure check ...
bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart
On Wed, 2003-02-05 at 16:05, Michael Stefaniuc wrote:
On Wed, Feb 05, 2003 at 01:47:46PM -0800, Francois Gouget wrote:
On Wed, 5 Feb 2003, Michael Stefaniuc wrote:
Hello,
i hate to reply to myself but here is Ingo's answer: | could you try: | | export LD_ASSUME_KERNEL=2.2.5 | | prior starting up Wine, does this fix the problem for you?
According to reports on the CrossOver mailing lists this works on Phoebe 1 but does not work anymore on Phoebe 2. Phoebe 2 had kernel-2.4.20-2.21 and that one had some problems with signals. Usable for wine are kernels starting with kernel-2.4.20-2.30. The actual kernel in rawhide is 2.4.20-2.34; i'll test tomorrow wine on Phoebe 2 with the actual kernel.
I'm running Mandrake 9.1 b3, and unfortunately I don't have a stock kernel, but I recompiled based on what's on the cooker, and just added an extra module. I'm running 2.4.21-pre4-1mdk, with glibc 2.3.1-7mdk I just compiled Wine cvs from about 2weeks ago, and it's working fine. Hopefully it'll still work with the final release.. (CXOffice just works, but my CXPlugin is currently broken..) Rick
Also it causes Wine to fail on some platforms like SuSE 8.1 so it should not be blindly set. Yet another configure check ...
bye michael -- -- Rick Romero IT Manager Valeo, Inc. ph: 262.695.4841 Sussex, WI. fax: 262.695.4850 Rick(a)valeoinc.com
On Wed, Feb 05, 2003 at 11:05:08PM +0100, Michael Stefaniuc wrote:
On Wed, Feb 05, 2003 at 01:47:46PM -0800, Francois Gouget wrote:
On Wed, 5 Feb 2003, Michael Stefaniuc wrote:
i hate to reply to myself but here is Ingo's answer: | could you try: | | export LD_ASSUME_KERNEL=2.2.5 | | prior starting up Wine, does this fix the problem for you?
According to reports on the CrossOver mailing lists this works on Phoebe 1 but does not work anymore on Phoebe 2. Phoebe 2 had kernel-2.4.20-2.21 and that one had some problems with signals. Usable for wine are kernels starting with kernel-2.4.20-2.30. The actual kernel in rawhide is 2.4.20-2.34; i'll test tomorrow wine on Phoebe 2 with the actual kernel. Ok, i've checked Phoebe2 with kernel 2.4.20-2.33 and the LD_ASSUME_KERNEL workaround and wine seems to work just fine. This should give us some time to move to pthreads.
bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart
Michael Stefaniuc wrote:
| export LD_ASSUME_KERNEL=2.2.5
Ok, i've checked Phoebe2 with kernel 2.4.20-2.33 and the LD_ASSUME_KERNEL workaround and wine seems to work just fine. This should give us some time to move to pthreads.
That's fantastic! I feel much less worried now. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
On Thu, 6 Feb 2003, Michael Stefaniuc wrote: [...]
Ok, i've checked Phoebe2 with kernel 2.4.20-2.33 and the LD_ASSUME_KERNEL workaround and wine seems to work just fine. This should give us some time to move to pthreads.
Well, I'm more pessimistic. Unfortunately LD_ASSUME_KERNEL is not a viable long-term solution. So we need to investigate the new threading model and make sure it is usable by Wine before things get set in concrete. I guess this means we need to be done well before RedHat Phoebe is released. Debian Unstable has the new glibc too but its release is most likely quite a bit further away<g>. However I would like this issue to be resolved by the time the new library hits Debian Testing ;-) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy
Michael Stefaniuc a écrit:
Hello,
i hate to reply to myself but here is Ingo's answer: | could you try: | | export LD_ASSUME_KERNEL=2.2.5 | | prior starting up Wine, does this fix the problem for you? | | I'm talking to Alexandre wrt. the threading rewrite - it will be | problematic (release-management wise) but is unavoidable.
I'm building now wine on Phoebe and test if the workaround will work, but it will take some time cause the box is only a PII-450.
bye michael
I recall seeing this trick for getting some Java VM work correctly with Mozilla (in the wrapper script for Moz). The specific JVM version is 1.3.0*. The script is scarce on details, as why or since when. Could it be the same problem here? Vincent
On Wed, Feb 05, 2003 at 01:47:54PM -0500, Dimitrie O. Paun wrote:
On Wed, 5 Feb 2003, Geoff Thorpe wrote: This is an interesting question. I know Ingo Molnar has been (one of) the main developer working on the glibc threading stuff, and I also know he used to follow the Wine project. I am sure he's not indifferent to our To resolve any doubts that Ingo isn't taking care of wine read this: http://lwn.net/Articles/6972/
fate, and being so deeply involved with the glibc changes, he's probably an invaluable resource. Unfortunately, I'm not sure he's even aware of the problem -- has anyone contacted him? Anyone want to do so? (Dan? :))
bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart
* Michael Stefaniuc (mstefani(a)redhat.de) wrote:
On Wed, Feb 05, 2003 at 01:47:54PM -0500, Dimitrie O. Paun wrote:
On Wed, 5 Feb 2003, Geoff Thorpe wrote: This is an interesting question. I know Ingo Molnar has been (one of) the main developer working on the glibc threading stuff, and I also know he used to follow the Wine project. I am sure he's not indifferent to our To resolve any doubts that Ingo isn't taking care of wine read this: http://lwn.net/Articles/6972/
That does indeed suggest that Ingo is "on this". Thank god too, I've just been following up on my hollow words with some attempts to look at the wine code and start finding my way around. That threading stuff is some deep code, and profoundly uninviting. I hope that Ingo's kernel patch (and Alexandre's mention in the mail and address in the CC line) indicate that higher powers are already on top of this problem? Cheers, Geoff -- Geoff Thorpe geoff(a)geoffthorpe.net http://www.geoffthorpe.net/
Geoff Thorpe wrote:
* Michael Stefaniuc (mstefani(a)redhat.de) wrote:
On Wed, Feb 05, 2003 at 01:47:54PM -0500, Dimitrie O. Paun wrote:
On Wed, 5 Feb 2003, Geoff Thorpe wrote: This is an interesting question. I know Ingo Molnar has been (one of) the main developer working on the glibc threading stuff, and I also know he used to follow the Wine project. I am sure he's not indifferent to our
To resolve any doubts that Ingo isn't taking care of wine read this: http://lwn.net/Articles/6972/
That does indeed suggest that Ingo is "on this". Thank god too, I've just been following up on my hollow words with some attempts to look at the wine code and start finding my way around. That threading stuff is some deep code, and profoundly uninviting. I hope that Ingo's kernel patch (and Alexandre's mention in the mail and address in the CC line) indicate that higher powers are already on top of this problem?
I couldn't help but notice that the date on that was 7 Aug 2002. It would be interesting to know what has gone on since then.
Duane Clark wrote:
I couldn't help but notice that the date on that was 7 Aug 2002. It would be interesting to know what has gone on since then.
Mostly just lots of work to stabilize the new glibc and kernel so that all apps still work, and the new thread stuff works and complies with Posix. See https://listman.redhat.com/pipermail/phil-list/ for an archive of the "native pthreads" mailing list. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
This is an interesting question. I know Ingo Molnar has been (one of) the main developer working on the glibc threading stuff, and I also know he used to follow the Wine project. I am sure he's not indifferent to our fate, and being so deeply involved with the glibc changes, he's probably an invaluable resource. Unfortunately, I'm not sure he's even aware of the problem -- has anyone contacted him? Anyone want to do so? (Dan? :))
I think it's safe to say the kernel and glibc team don't want to cause undue trouble for wine. If we run into serious roadblocks trying to adapt, they will probably be willing to help. However, we have to act soon, before things get even more frozen in place than they already are. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Geoff Thorpe wrote:
What disturbs me most about this pthread/glibc issue is the (apparent) impunity with which the glibc maintainer has just barged ahead with this disruptive change with (again, apparently) little concern for the fallout it would cause.
I agree the glibc maintainer is headstrong, but in this case he is right. Linux's pthread support needed improving, and the improvements required fundamental changes. I suspect that even if he had gone with ngpt instead of his own nptl, Wine would have suffered similar disruptions. See http://www.kegel.com/c10k.html#threaded for a little background. In short, my opinion is Wine really should just roll with the punches here. We'll benefit, too, in the end.
Dan - if you want to co-ordinate this and are willing to accommodate my coming to grips with the wine specifics (have you ever contemplated a less precise request for help? :-), please get in touch via private email and I'll do what I can to contribute, investigate, research, hack, whatever.
If I get into this, I'll post on the list. I may not be the right person to coordinate it, since my time is limited, but I'll certainly help according to my abilities. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
* Dan Kegel (dank(a)kegel.com) wrote:
Geoff Thorpe wrote:
What disturbs me most about this pthread/glibc issue is the (apparent) impunity with which the glibc maintainer has just barged ahead with this disruptive change with (again, apparently) little concern for the fallout it would cause.
I agree the glibc maintainer is headstrong, but in this case he is right. Linux's pthread support needed improving, and the improvements required fundamental changes. I suspect that even if he had gone with ngpt instead of his own nptl, Wine would have suffered similar disruptions.
See http://www.kegel.com/c10k.html#threaded for a little background.
In short, my opinion is Wine really should just roll with the punches here. We'll benefit, too, in the end.
No doubt, and I take your point about the best decisions not always involving the least work. I just consider that it would be a huge backwards step if upcoming linux distribution releases neither had wine in them nor supported wine being installed onto a default setup. There must be very few projects either using or bypassing their systems' pthreads implementations who have the complications to deal with that wine has, so that must obviously be part of the problem - working around glibc's thread-changes is probably not too hard for "most people". Nonetheless, it is pretty essential that wine's problem get resolved before these incompatible versions start making it into mainstream distributions - glibc and linux distribution people leaving wine behind would not help anyone. Do we have a definitive explanation of just how bad the current wine/pthread incompatibilities are, and/or where current efforts are at? I'd not known there were any efforts to get wine working with nptl (hence my perhaps exaggerated alarm) until the link to Ingo's kernel patch was posted (aug2002 moreover) which suggests at least that some people *are* working on this (phew). I would be very grateful to know what the status is. Anyone? TIA. Cheers, Geoff -- Geoff Thorpe geoff(a)geoffthorpe.net http://www.geoffthorpe.net/
Geoff Thorpe wrote:
Nonetheless, it is pretty essential that wine's problem get resolved before these incompatible versions start making it into mainstream distributions - glibc and linux distribution people leaving wine behind would not help anyone.
Agreed.
Do we have a definitive explanation of just how bad the current wine/pthread incompatibilities are, and/or where current efforts are at?
Not many people are running the new glibc+kernel combination. It's been hard to do until recently. I think the key thing for the moment is to get a few developers set up with it (either via Red Hat 8.1 beta, or via Gentoo (more work, but much more control), or maybe a Suse beta).
I'd not known there were any efforts to get wine working with nptl (hence my perhaps exaggerated alarm) until the link to Ingo's kernel patch was posted (aug2002 moreover) which suggests at least that some people *are* working on this (phew).
That patch only indicates that Ingo was *anticipating* this issue, and leaving room for an eventual solution. I don't think he's working on Wine threads.
I would be very grateful to know what the status is. Anyone? TIA.
IMHO the status is "the new stuff is ready and waiting for the wine developers to install on their machines, and start working on converting Wine threads to be based on top of posix threads instead of the low-level stuff they currently use." - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
* Dan Kegel (dank(a)kegel.com) wrote:
Not many people are running the new glibc+kernel combination. It's been hard to do until recently.
I think the key thing for the moment is to get a few developers set up with it (either via Red Hat 8.1 beta, or via Gentoo (more work, but much more control), or maybe a Suse beta).
Perhaps compiling a UML 2.5.*-based kernel and making a small LFS-style root filesystem downloadable would be a good idea? I agree the development problem is likely to be aggravated by few developers having any great desire to work inside such a flakey, bleeding edge system as the modern kernel and glibc would currently require, so perhaps a UML environment (with multiple "before and after" kernel versions) would feel more comfortable? I happen to follow the UML mail lists (for similar reasons to why I monitor the wine project) and I suspect there are some people and tools there that might help us if we want and/or need them. However, I think the question is for those wine developers that grok and hack the threading code; is there something along these lines I (and/or anyone else) could do to help you? Cheers, Geoff -- Geoff Thorpe geoff(a)geoffthorpe.net http://www.geoffthorpe.net/
Geoff Thorpe wrote:
Perhaps compiling a UML 2.5.*-based kernel and making a small LFS-style root filesystem downloadable would be a good idea?
Yes, that would probably help. It would have to include the latest glibc, etc (see https://listman.redhat.com/pipermail/phil-list/2003-February/000541.html for *exactly* which glibc to use). This environment would both let anyone verify that Wine doesn't run in that environment, and provide a posix-compatible threading environment to use to test winethreads-over-pthreads. However, it's not clear to me that's required for developing winethreads-over-pthreads. People could probably get started on that with their current Linux, even though it's not 100% posix-compliant, and has odd quirks like using a special management thread, etc.
However, I think the question is for those wine developers that grok and hack the threading code; is there something along these lines I (and/or anyone else) could do to help you?
Yeah, all you wine threading gurus, please speak up :-) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Dan Kegel wrote:
However, it's not clear to me that's required for developing winethreads-over-pthreads. People could probably get started on that with their current Linux, even though it's not 100% posix-compliant, and has odd quirks like using a special management thread, etc.
Exactly. Who's going to start it? Actually this message is just to say that I think we should change the subject of this thread... David
David Fraser wrote:
Dan Kegel wrote:
However, it's not clear to me that's required for developing winethreads-over-pthreads. People could probably get started on that with their current Linux, even though it's not 100% posix-compliant, and has odd quirks like using a special management thread, etc.
Exactly. Who's going to start it?
According to a recent post, a quick try at basing things on pthreads is at http://www.geocrawler.com/archives/3/9376/2001/12/50/7309863/ but I guess there's more to be done. So the question is, who's going to be the first to get a "new pthreads" Linux system up and running to verify the problem and try out that patch? (http://kt.zork.net/wine/wn20030131_155.html#2 has a nice summary of recent discussions, but searching google for wine pthreads yields a few interesting tidbits, too.) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Dan Kegel wrote:
David Fraser wrote:
Dan Kegel wrote:
However, it's not clear to me that's required for developing winethreads-over-pthreads. People could probably get started on that with their current Linux, even though it's not 100% posix-compliant, and has odd quirks like using a special management thread, etc.
Exactly. Who's going to start it?
According to a recent post, a quick try at basing things on pthreads is at http://www.geocrawler.com/archives/3/9376/2001/12/50/7309863/ but I guess there's more to be done. So the question is, who's going to be the first to get a "new pthreads" Linux system up and running to verify the problem and try out that patch?
(http://kt.zork.net/wine/wn20030131_155.html#2 has a nice summary of recent discussions, but searching google for wine pthreads yields a few interesting tidbits, too.) - Dan
Seeing as nobody talked about this for a while, I decided to take this patch and integrate it into my CVS copy... I did and the relevant files compile fine, with one warning gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -Wpointer-arith -mpreferred-stack-boundary=2 -gstabs+ -fPIC -D__WINESRC__ -D_NTSYSTEM_ -DBINDIR="\"/usr/local/bin\"" -DETCDIR="\"/usr/local/etc\"" -D_REENTRANT -o ../../scheduler/sysdeps.o ../../scheduler/sysdeps.c ../../scheduler/sysdeps.c: In function `SYSDEPS_SpawnThread': ../../scheduler/sysdeps.c:219: warning: passing arg 3 of `pthread_create' from incompatible pointer type Not being an autoconf wizard I had to define USE_PTHREADS manually in the files ... how could I add a --enable-pthreads switch? When compiled, gave me the following error linking wine in miscemu: gcc -o wine wine.spec.o main.o -L../dlls -lntdll.dll -L../library -lwine -L../unicode -lwine_unicode -lm ../dlls/libntdll.dll.so: undefined reference to `pthread_create' ../dlls/libntdll.dll.so: undefined reference to `pthread_attr_setstackaddr' ../dlls/libntdll.dll.so: undefined reference to `pthread_once' ../dlls/libntdll.dll.so: undefined reference to `pthread_attr_setstacksize' ../dlls/libntdll.dll.so: undefined reference to `pthread_join' collect2: ld returned 1 exit status make[1]: *** [wine] Error 1 If I tried to add libpthread, I got: gcc -o wine wine.spec.o main.o -L../dlls -lntdll.dll -L../library -lwine -L../unicode -lwine_unicode -lm -lpthread ../dlls/libntdll.dll.so: the use of `pthread_attr_setstackaddr' is deprecated, use `pthread_attr_setstack' so I replaced that, and it got rid of the warning... Then everything links fine, but running gives an error because of an assert in library/port.c because the pthread functions in scheduler/pthreads.c had been compiled out in the patch. I compiled them back in and wine just hangs... Hmmmm .... not very useful to anyone but I'd thought I'd let you know. If anyone wants I can post the patch (to wine-patches?) David
Do we have a definitive explanation of just how bad the current wine/pthread incompatibilities are, and/or where current efforts are at? I'd not known there were any efforts to get wine working with nptl (hence my perhaps exaggerated alarm) until the link to Ingo's kernel patch was posted (aug2002 moreover) which suggests at least that some people *are* working on this (phew). I would be very grateful to know what the status is. Anyone? TIA.
There are no known current efforts. However I talked to Ulrich today and he said (and I agree) that it will be way easier to implement threading on top of (nptl) pthreads today. Just no one started/did it yet. And we do not need the glibc developers, the ball is in our park ;) Ciao, marcus
Do we have a definitive explanation of just how bad the current wine/pthread incompatibilities are, and/or where current efforts are at? I'd not known there were any efforts to get wine working with nptl (hence my perhaps exaggerated alarm) until the link to Ingo's kernel patch was posted (aug2002 moreover) which suggests at least that some people *are* working on this (phew). I would be very grateful to know what the status is. Anyone? TIA.
among the things we have to take care of: - signals: signal, in current implementation, is sent to a thread. in nptl, it's sent to the process. So, lots of thread control has to be rewritten - in the same type of issues, getpid() now returns the same pid for all threads in a same process. Most of Wine code relies on having a different pid for each thread (this fix is needed, IIRC, for some Solaris port) from what I've seen, the LDT/GDT with nptl should be easier: - for Win32 processes, as Ulrich already wrote, we could got rid of LDT (and only rely on GDT) for %fs and TEB allocation - for Win16 processes, we would still require LDT sharing across pthreads, which I don't how it's handled right now and it's likely there are quite a few other items I forgot A+ -- Eric Pouech
Eric Pouech wrote:
among the things we have to take care of: - signals: signal, in current implementation, is sent to a thread. in nptl, it's sent to the process. So, lots of thread control has to be rewritten - in the same type of issues, getpid() now returns the same pid for all threads in a same process. Most of Wine code relies on having a different pid for each thread (this fix is needed, IIRC, for some Solaris port)
I think this is mostly used to implement SuspendThread / ResumeThread, which cannot be portably implemented using the pthreads interface. I do not know how to solve this issue without relying on implementation details ...
from what I've seen, the LDT/GDT with nptl should be easier: - for Win32 processes, as Ulrich already wrote, we could got rid of LDT (and only rely on GDT) for %fs and TEB allocation - for Win16 processes, we would still require LDT sharing across pthreads, which I don't how it's handled right now
LDT sharing should not be a problem (there were bugs in kernels 2.0.x w.r.t. that issue, but those are long since fixed). The core problem with the LDT was that the LinuxThreads implementation used to allocate entries with modify_ldt, and Wine would do the same, without any coordination between the two. This is no longer a problem as the new ntpl thread library does not use the LDT at all anymore. Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de
Following up on myself:
Eric Pouech wrote:
among the things we have to take care of: - signals: signal, in current implementation, is sent to a thread. in nptl, it's sent to the process. So, lots of thread control has to be rewritten - in the same type of issues, getpid() now returns the same pid for all threads in a same process. Most of Wine code relies on having a different pid for each thread (this fix is needed, IIRC, for some Solaris port)
I think this is mostly used to implement SuspendThread / ResumeThread, which cannot be portably implemented using the pthreads interface. I do not know how to solve this issue without relying on implementation details ...
However, at least in the Linux / glibc 2.3.x case, there's a new gettid call that returns a 'thread ID' that used to be the pid, and a new tkill system call that can be used to send a signal to one TID, just like the old Linux kill would send a signal to a specific thread. I think using those we could carry over our old Linux-specific hacks one to one, and it still should work even if our threads are glibc 2.3.x pthreads. Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de
However, at least in the Linux / glibc 2.3.x case, there's a new gettid call that returns a 'thread ID' that used to be the pid, and a new tkill system call that can be used to send a signal to one TID, just like the old Linux kill would send a signal to a specific thread. I think using those we could carry over our old Linux-specific hacks one to one, and it still should work even if our threads are glibc 2.3.x pthreads.
sounds better !! the other issue would the maintainability of all this stuff... and also, our unability to convert this to other POSIX pthreads implementations (Solaris...) but, at least, it looks like a road to follow A+ -- Eric Pouech
Ulrich Weigand wrote:
Eric Pouech wrote:
among the things we have to take care of: - signals: signal, in current implementation, is sent to a thread. in nptl, it's sent to the process. So, lots of thread control has to be rewritten - in the same type of issues, getpid() now returns the same pid for all threads in a same process. Most of Wine code relies on having a different pid for each thread (this fix is needed, IIRC, for some Solaris port)
I think this is mostly used to implement SuspendThread / ResumeThread, which cannot be portably implemented using the pthreads interface. I do not know how to solve this issue without relying on implementation details ...
this is also used in the debugging API support in the kernel (which you can see as an extension of SuspendThread / ResumeThread) I don't see any way to actually stop a pthread (unless changing its scheduling policy&priority, but rather ugly) (pthread_suspend seems to have been implemented in some pt libs, but isn't in the opengroup specs standard AFAICS) which may be quite an issue
from what I've seen, the LDT/GDT with nptl should be easier: - for Win32 processes, as Ulrich already wrote, we could got rid of LDT (and only rely on GDT) for %fs and TEB allocation - for Win16 processes, we would still require LDT sharing across pthreads, which I don't how it's handled right now
LDT sharing should not be a problem (there were bugs in kernels 2.0.x w.r.t. that issue, but those are long since fixed). The core problem with the LDT was that the LinuxThreads implementation used to allocate entries with modify_ldt, and Wine would do the same, without any coordination between the two. This is no longer a problem as the new ntpl thread library does not use the LDT at all anymore.
I thought there were also issues where a LDT wasn't correctly inherited thru clone(), but I may be mistaken on that one. A+ -- Eric Pouech
Eric Pouech wrote:
Ulrich Weigand wrote:
LDT sharing should not be a problem (there were bugs in kernels 2.0.x w.r.t. that issue, but those are long since fixed). The core problem with the LDT was that the LinuxThreads implementation used to allocate entries with modify_ldt, and Wine would do the same, without any coordination between the two. This is no longer a problem as the new ntpl thread library does not use the LDT at all anymore. I thought there were also issues where a LDT wasn't correctly inherited thru clone(), but I may be mistaken on that one.
That's the 2.0.x issue I was talking about. I'm not aware of LDT sharing problems with more recent kernels. In any case, we are using clone right now, and do share LDTs, so it should work just the same if clone is called via pthread_create ... Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de
On Thu, 6 Feb 2003, Eric Pouech wrote: [...]
- in the same type of issues, getpid() now returns the same pid for all threads in a same process. Most of Wine code relies on having a different pid for each thread (this fix is needed, IIRC, for some Solaris port)
Yes it's needed for Solaris (x86&sparc). I started a patch a long time ago but never finished it. It can probably be found somewhere in the wine-devel archives together with interesting descriptions and discussions of the issue. If necessary I could try to dig out the patch but it's quite likely to be pretty out of date. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ $live{free} || die "";
Geoff Thorpe <geoff(a)geoffthorpe.net> writes:
Do we have a definitive explanation of just how bad the current wine/pthread incompatibilities are, and/or where current efforts are at? I'd not known there were any efforts to get wine working with nptl (hence my perhaps exaggerated alarm) until the link to Ingo's kernel patch was posted (aug2002 moreover) which suggests at least that some people *are* working on this (phew). I would be very grateful to know what the status is. Anyone? TIA.
I've been in touch with Ingo, and I'm looking into the issue. However I'm currently moving, so things are a bit hectic around here, and I don't have good internet access. Hopefully things will settle down a bit soon so that I can get some real work done... -- Alexandre Julliard julliard(a)winehq.com
On Thu, 2003-02-06 at 15:10, Alexandre Julliard wrote:
Geoff Thorpe <geoff(a)geoffthorpe.net> writes:
Do we have a definitive explanation of just how bad the current wine/pthread incompatibilities are, and/or where current efforts are at? I'd not known there were any efforts to get wine working with nptl (hence my perhaps exaggerated alarm) until the link to Ingo's kernel patch was posted (aug2002 moreover) which suggests at least that some people *are* working on this (phew). I would be very grateful to know what the status is. Anyone? TIA.
I've been in touch with Ingo, and I'm looking into the issue. However I'm currently moving, so things are a bit hectic around here, and I don't have good internet access. Hopefully things will settle down a bit soon so that I can get some real work done...
I realize that this discussion is targeted at a real solution to the problem, however some of us are already in the situation and are too dumb to know how to deal with it. On the RedHat Phoebe (Beta versions already exhibit this problem) it was said that using LD_ASSUME_KERNEL=2.2.5 would solve the problem but that didn't work for me. However, there was a workaround on the vmware newsgroup (vmware is afflicted with a similar disease) that preloads a small .so to make it work. This might be useful for some people. I've used it with some success on my installation of wine. I've attached the modified newsgroup posting below in case someone else would like it. <stolen from newsgroup and modified> In the interest of posterity (and helping anyone else using wine with rawhide glibc), here's what ended up working. Compile the attached file q.c into q.so. Put q.so into /usr/lib/, and chmod it 555. Then rename the files /opt/wine/bin/wine.bin, giving it a (second) ".bin" extension. Then create two new files named /opt/wine/bin/wine-bin instead that contain: ------------------- #!/bin/bash LD_PRELOAD=q.so exec "$0.bin" "$@" ------------------- chmod a+rx these new files, and all should be well. The basic problem is that vmware binaries have their own copy of errno and related functions, and there is a clash with the new glibc ones. q.so will resolve this problem. The need for the scripts above arises from the fact that each of the binaries launched by the initial /opt/wine/bin/wine.bin call needs to have the q.so preloaded. q.c was written by Petr Vendrovec, and many thanks go to him for the work he put into the debugging of the problem and the attached code! In summary, q.c qorreqts the formerly inqurable qrashes. ------------------------------------------------------- /* * Build with: gcc -W -Wall -shared -o q.so q.c */ #include <dlfcn.h> #include <sys/mman.h> #include <stdlib.h> #include <stdio.h> void go(void) __attribute__((constructor)); void go(void) { void* qh; unsigned char *__real_errno_location, *__vm_errno_location; qh = dlopen("libc.so.6", RTLD_GLOBAL); __real_errno_location = dlsym(qh, "__errno_location"); __vm_errno_location = dlsym(NULL, "__errno_location"); printf("Got eroloc %p & %p\n", __vm_errno_location, __real_errno_location); if (__real_errno_location && __vm_errno_location && __real_errno_location != __vm_errno_location) { unsigned int errnobase = (int)__vm_errno_location; unsigned int mpbase = errnobase & ~0xFFF; unsigned int mplen = 4096; if (errnobase + 5 > mpbase + mplen) { mplen = mplen + 4096; } mprotect((void*)mpbase, mplen, PROT_READ|PROT_WRITE|PROT_EXEC); *__vm_errno_location = 0xE9; *(int*)(__vm_errno_location + 1) = __real_errno_location - __vm_errno_location - 5; mprotect((void*)mpbase, mplen, PROT_READ|PROT_EXEC); } } ------------------------------------------------------- </stolen from newsgroup and modified> I make no guarantees that this will work, but I'm hopeful. -- Chris Tooley <chris(a)tooley.com>
On Thu, Feb 06, 2003 at 03:31:52PM -0600, Chris Tooley wrote:
On Thu, 2003-02-06 at 15:10, Alexandre Julliard wrote:
Geoff Thorpe <geoff(a)geoffthorpe.net> writes:
Do we have a definitive explanation of just how bad the current wine/pthread incompatibilities are, and/or where current efforts are at? I'd not known there were any efforts to get wine working with nptl (hence my perhaps exaggerated alarm) until the link to Ingo's kernel patch was posted (aug2002 moreover) which suggests at least that some people *are* working on this (phew). I would be very grateful to know what the status is. Anyone? TIA.
I've been in touch with Ingo, and I'm looking into the issue. However I'm currently moving, so things are a bit hectic around here, and I don't have good internet access. Hopefully things will settle down a bit soon so that I can get some real work done...
I realize that this discussion is targeted at a real solution to the problem, however some of us are already in the situation and are too dumb to know how to deal with it. On the RedHat Phoebe (Beta versions already exhibit this problem) it was said that using LD_ASSUME_KERNEL=2.2.5 would solve the problem but that didn't work for me. However, there was a workaround on the vmware newsgroup (vmware is afflicted with a similar disease) that preloads a small .so to make it work. This might be useful for some people. I've used it with some success on my installation of wine. I've attached the modified newsgroup posting below in case someone else would like it.
I posted the same thing 2 weeks ago on wine-patches if someone wants to go that way for now ;) It will not work when the NPTL threading is enabled, see the other discussions. Ciao, Marcus
On Thu, Feb 06, 2003 at 03:31:52PM -0600, Chris Tooley wrote:
On Thu, 2003-02-06 at 15:10, Alexandre Julliard wrote:
Geoff Thorpe <geoff(a)geoffthorpe.net> writes:
Do we have a definitive explanation of just how bad the current wine/pthread incompatibilities are, and/or where current efforts are at? I'd not known there were any efforts to get wine working with nptl (hence my perhaps exaggerated alarm) until the link to Ingo's kernel patch was posted (aug2002 moreover) which suggests at least that some people *are* working on this (phew). I would be very grateful to know what the status is. Anyone? TIA.
I've been in touch with Ingo, and I'm looking into the issue. However I'm currently moving, so things are a bit hectic around here, and I don't have good internet access. Hopefully things will settle down a bit soon so that I can get some real work done...
I realize that this discussion is targeted at a real solution to the problem, however some of us are already in the situation and are too dumb to know how to deal with it. On the RedHat Phoebe (Beta versions already exhibit this problem) it was said that using LD_ASSUME_KERNEL=2.2.5 would solve the problem but that didn't work for me. However, there was a workaround on the vmware newsgroup (vmware is Even simpler and much better take the kernel from rawhide, at the moment that's version 2.4.20-2.34 but any kernel starting with 2.4.20-2.30 should work. I tested it myself with 2.4.20-2.33 .
bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart
Michael Stefaniuc wrote:
I realize that this discussion is targeted at a real solution to the problem, however some of us are already in the situation and are too dumb to know how to deal with it. On the RedHat Phoebe (Beta versions already exhibit this problem) it was said that using LD_ASSUME_KERNEL=2.2.5 would solve the problem but that didn't work for me. However, there was a workaround on the vmware newsgroup (vmware is
Even simpler and much better take the kernel from rawhide, at the moment that's version 2.4.20-2.34 but any kernel starting with 2.4.20-2.30 should work. I tested it myself with 2.4.20-2.33 .
We might want to run some tests to verify the new threading code is actually present and working. Maybe run some of the regression tests that come with NGPT or NPTL, say. Otherwise it's possible the new system is still using old threads. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Dimitrie O. Paun wrote:
On February 5, 2003 03:36 am, David Fraser wrote:
Under cygwin, there is no clone call as far as I can make out ... there is pthreads support and there is hackish support for fork.
Do threads in Cygwin's pthreads map one-to-one to Windows threads?
Just looked at the Cygwin source, and it looks like they do. pthread::create in src/winsup/cygwin/thread.cc calls native Windows ::CreateThread and stores the returned HANDLE in win32_obj_id (a member of the pthread class). This is then accessible as (*thread)->win32_obj_id from the pthread_t *thread pointer. So that looks sufficient ... if Wine can use ptherads... David
participants (22)
-
Alexandre Julliard -
Chris Tooley -
Dan Kegel -
David Fraser -
Dimitrie O. Paun -
Dimitrie O. Paun -
Duane Clark -
Eric Pouech -
Francois Gouget -
Geoff Thorpe -
Gregory M. Turner -
Jeremy White -
Marcus Meissner -
Marcus Meissner -
Michael Stefaniuc -
Mike Hearn -
Mike Hearn -
Phil Bordelon -
Rick Romero -
Steven Edwards -
Ulrich Weigand -
Vincent Béron