epoll, LSB (was: Re: Problem roundup)
wine-devel at shemesh.biz
Sat Nov 20 13:33:45 CST 2004
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
>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
>>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
>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.
Lingnu Open Source Consulting ltd.
More information about the wine-devel