Problem roundup

[Peter Hunnisett]

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
>
>
>  
>