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
* Dan Kegel ([EMAIL PROTECTED]) 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
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
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
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
And we do not need the glibc developers, the ball is in our park ;)
Presuming we knock the ball out of the park, do we have any
hope for backwards compatibility (in other words, can
we build a flavor of Wine that will work both on glibc 2.3
and glibc 2.2?)
Jer
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
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
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
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
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
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
Geoff Thorpe [EMAIL PROTECTED] 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
On Thu, 2003-02-06 at 15:10, Alexandre Julliard wrote:
Geoff Thorpe [EMAIL PROTECTED] 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
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
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 [EMAIL PROTECTED] writes:
Do we have a definitive explanation of just how bad the current
wine/pthread incompatibilities are, and/or where current efforts
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
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
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
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
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?!?
--
Dimi.
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
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
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
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
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
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
* Dan Kegel ([EMAIL PROTECTED]) 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
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
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
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
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)
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
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
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)
* Michael Stefaniuc ([EMAIL PROTECTED]) 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
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
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
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
Geoff Thorpe wrote:
* Michael Stefaniuc ([EMAIL PROTECTED]) 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
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
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
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.
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
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
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
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
47 matches
Mail list logo
