Started playing with Wineserver on mingw/cygwin again
Gregory M. Turner
gmturner007 at ameritech.net
Wed Feb 5 14:39:46 CST 2003
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!
More information about the wine-devel
mailing list