epoll, LSB (was: Re: Problem roundup)

[Shachar Shemesh]

Mike Hearn wrote:

>There have been discussions about this on fedora-devel, I think the
>conclusion was that you don't need to do this. Basically compiling for
>i586 using athlon scheduling should give great results on all processors
>even P4 due to the internal chip designs, or somesuch. 
>
>I think an i686 build of Wine will bear close resemblance to an i386 
>build as we have no hand written assembly that would benefit and 
>the new instruction i686 provides over i586 is quite specialist
>and not used by gcc nor Wine. 
>
>At least this is my understanding.
>  
>
No, that's not what optimizing does. The instruction set of all CPUs 
since 386 is virtually identical, and since 486 is almost completely 
identical. HOWEVER, different internal CPU structure means that the CPUs 
progressively approach the RISC architecture.

One of the characteristics of the RISC architecture is that the compiler 
is very aware of internal CPU structures, pipeline lengths and bubbles. 
When you switch on i686 optimization, actual produced instructions would 
probably not differ much. What would differ is the order in which they 
are produced. Code optimized for 686 would run on 586 (and probably 486 
as well), but not run as fast.

I don't know how significant this impact is. Wine is not very CPU 
intensive. It's just something to keep in mind.

>>Compound that with the fact that I provide for quite a few older
>>versions of RH (RH7.3, RH8, RH9) and FC (FC1, FC2, soon FC3) and WBEL
>>(WBEL 3), and that there are wine-devel packages too (only the i386
>>flavor), and you get the big quantity of packages there are.
>>    
>>
>
>Yes while we're on the subject the FC2 RPMs are compiled with libICU
>giving GDI32 a dependency on libstdc++ 5, whereas FC3 apparently only
>installs libstdc++ 6 by default requiring the user to install
>compat-libstdc++ (assuming they can diagnose the linker/rpm error of
>course). 
>
>This came to light because a user tried to install the FC2 RPM on FC3 due
>to lack of FC3 RPMs.
>  
>
Hmm. Would separating the BiDi code (which is the reason ICU is linked 
with GDI) into a separate DLL (they way it is on Windows 2000) help? 
It's something I want to do anyways because:
1. It's how it is on Windows.
2. It would probably allow CrossOver to come with BiDi support.
3. GDI is not the only BiDi consumer. Specifically, DrawText needs to be 
BiDi aware, as well as the Edit control.

This would mean that the same problem would still happen for Israeli and 
Arabic speaking wine users needing FC3 RPMs, but it would not block 
everyone.

>>Do you think I should add an explicit dependancy on the redhat-release
>>(or fedora-release) package, so people don't install them on the wrong
>>distribution?
>>    
>>
>
>That might help yes.
>  
>
I hate that solution. I've been bitten by overly strict dependencies 
before. If you require libstdc++5, mark as depending on it. Same goes 
for libc versions.

>>Also, don't forget the people which will try to install a Mandrake rpm
>>on SuSE, or a SuSE one on RH (without any thought about the versions
>>involved). It's a mess, but Wine does some things so close to glibc that
>>it's difficult to provide a "one binary fits all" without compiling an a
>>very old setup (such as what Mozilla and probably CX do).
>>    
>>
Personally, I think the right way to solve that one is to fix the 
dependencies in the spec file. I don't see any reason for a RH RPM to 
install on SUSE and not run. If it installs, it should run. If there are 
library differences, it shouldn't install, citing the library it needs.

          Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/