On Sat, 20 Nov 2004 10:34:17 -0500, Vincent Béron wrote:
That's partly because for myself I like (for no other reason than "I can") to have a build optimized for my architecture, which is athlon. Building it means uploading it is only a few more minutes. Then, knowing that a lot of other people don't run an athlon, but a P4 (or earlier processors), I also provide i686 and i386 builds.
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.
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.
The name and version number of the target is in the rpm filename, so it should be easy to pick the good one.
People choosing the wrong RPM is a very common mistake.
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.
In the past I did get a few (less than 10 probably) emails asking which package to download for such or such version, but taking into account the number of successful downloads for those same versions, that's not a big percentage (IMHO).
Well you're assuming everybody who gets the wrong one emails you rather than asks in #winehq, #linuxhelp, linuxquestions.org, friend, relative, whatever.
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).
Actually we recently upgraded our build machine at CodeWeavers to a more modern release. Also there's nothing magical about this, the reason you "have" to compile on older systems is:
a) Libraries on Linux generally don't use header guards like Windows does. Library authors love to give you automatic dependencies on modern library versions because, you know, the new features are so cool who *wouldn't* want them (thread-local locales, GDK lock hooks, etc). Note the sarcasm there ....
b) glibc uses a bizarre form of symbol overloading whereby the version of the library you compile against selects which version of each function it will use at runtime. This is dumb because the differences between the versions are undocumented, and anyway even if they were plenty of users compile from the sources so there's no way to predict which version you'll actually get. It's possible to force usage of a particular symbol version using inline assembly, but this trick is known by hardly anybody and used by even fewer.
The vast majority of sensible libraries don't use this type of overloading. I'm not saying symbol versioning is bad, it's a good thing to tag the library with versions so the linker and RPM can know about minor versions. It's a bad idea IMHO to tag the same symbol with multiple versions, when you could just rename the symbol/library and retain portability + developer sanity.
c) The rollout of the table based exception handling ABI was bodged with libgcc and glibc 'fighting' over who contained the symbols. The end result is a mess of weak symbols, overridden symbols, automatic dependencies and obscure compiler switches. You only care about this if you want to run on pre-gcc3 systems which are these days increasingly rare. It's possible to fix by using the -shared-libgcc switch as long as you are willing to depend/ship libgcc yourself.
thanks -mike