epoll, LSB (was: Re: Problem roundup)

[Mike Hearn]

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