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 5, 2003 03:36 am, David Fraser wrote: Do threads in Cygwin's pthreads map one-to-one to Windows threads? 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, 5 Feb 2003, Marcus Meissner wrote: Duh! So what will it happen -- Wine will not run on RH 8.1?!? -- Dimi.

Mike Hearn a écrit: 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

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 Wednesday 05 February 2003 01:10 pm, Phil Bordelon wrote: 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!

* Dan Kegel (dank(a)kegel.com) wrote: 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, Feb 05, 2003 at 01:47:54PM -0500, Dimitrie O. Paun wrote: As far as I know he probably reads wine-devel too. He did the kernel stuff, the glibc part was done by Ulrich Drepper. He even follows rewind . 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: 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, 2003-02-05 at 16:05, Michael Stefaniuc wrote: 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 -- -- Rick Romero IT Manager Valeo, Inc. ph: 262.695.4841 Sussex, WI. fax: 262.695.4850 Rick(a)valeoinc.com

Michael Stefaniuc wrote: 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

Michael Stefaniuc a écrit: 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

* Michael Stefaniuc (mstefani(a)redhat.de) wrote: 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/

Duane Clark wrote: 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

Geoff Thorpe wrote: 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. 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

Geoff Thorpe wrote: Agreed. 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). 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. 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

Geoff Thorpe wrote: 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. 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

David Fraser wrote: 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

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

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

Following up on myself: 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

Ulrich Weigand wrote: 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 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

On Thu, 6 Feb 2003, Eric Pouech wrote: [...] 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 "";

On Thu, 2003-02-06 at 15:10, Alexandre Julliard 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 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 &lt;chris(a)tooley.com&gt;

On Thu, Feb 06, 2003 at 03:31:52PM -0600, Chris Tooley wrote: 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

Dimitrie O. Paun wrote: 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