Mike Hearn wrote:
On Fri, 2004-11-19 at 16:07, Vincent BÃron wrote:
If you're talking about this thread
(http://www.linuxquestions.org/questions/showthread.php?s=&threadid=252670), then I didn't reproduce it on my RH9 setup when I released 20041019 (I have a video card fan problem right now, so the video card in that computer is now in my main computer, so I can't test it just right now). I guess the user have a different kernel/glibc than I do (I'm using RH9+updates from RH for RH9+updates from FedoraLegacy for RH9 as of the releases of Wine). The epoll detection/support is not very robust yet it seems.
Hmm, OK. Actually there are several threads, just search for epoll_create on the forums. As long as you're aware of the issue I'm happy.
We should really be dynamically detecting this at runtime not compile time.
(Slightly OT: would autopackage help here?)
Well, maybe. The ethos of autopackage is "build once, install anywhere" so before packaging Wine as an autopackage I'd have done the work to make this dynamically loaded. Features enabled at compile time not runtime are e.v.i.l and should generally by regarded as bugs IMHO. The RPM ethos is the exact opposite: "build many, install once".
But the issue here is with Wine rather than the actual packaging technology in use.
Also, PICOspark mentions he gets the same error in WineX, which I
personnally find a bit strange.
That is a bit bizarre, I just checked and TG CVS appears to use standard
poll not epoll. But who knows what their binaries use.
Cedega does not use epoll anywhere. We've cut out most of the poll cost through using Shared Memory so it's not as much of a bottleneck.
Ciao, Peter
thanks -mike
