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