Problem roundup

[Vincent Béron]

Le ven 19/11/2004 à 15:42, Vincent Béron a écrit :
> Le ven 19/11/2004 à 15:07, Alexandre Julliard a écrit :
> > Mike Hearn <mike at navi.cx> writes:
> > 
> > > We don't have to be over-general about it, just dynamically loading the
> > > ones that cause problems would be fine (or using syscalls directly). The
> > > vast majority of the symbols are always there and so it doesn't make sense
> > > to use dlsym.
> > 
> > I think it's much better to ask packagers to build their packages
> > correctly, it will cause much less trouble in the long run.
> 
> That, or get the users to update their distribution (and optionnally not
> install core packages from somewhere else than their distributor).

I'm 99% positive that the problem is: users didn't update their
distribution.

RH9 shipped with glibc-2.3.2-11.9, for which a "grep -r epoll *" over
the files included in it yields nothing. Later, they shipped an update
to glibc, labelled glibc-2.3.2-27.9.7. That update somehow does support
epoll (same grep as above).

In the two answers I received so far, the original glibc-2.3.2-11.9 is
used, while I target an up-to-date RH9 (with FedoraLegacy updates since
RH dropped support for it). That politic is stated in the release notes
of the RH packages on sf.net (I don't know how many people do read them,
but they're there).

That problem couldn't be found by the internal rpm dependancy checker,
as both glibc identify themselves as up to GLIBC_2_3_3. An explicit
dependancy on glibc release number could be added, but I'm not positive
it's a good thing to target dependancies so precisely.

So all this boils down to is that RH shipped a glibc update which broke
backwards compatibility, with the same version number (glibc-2.3.2). A
Wine compiled on the newer version takes advantage of epoll support
being present, but will refuse to run on the older version. Furthermore,
some users seem OK with running unpatched installations of RH9, but do
track Wine snapshots I provide, and have been bitten by the mix above.

Now, the obvious question is how can we prevent that in the future?
Specify a glibc version-release (we'll get users rpm --force'ing it, a
future glibc update can (or not) break it, etc.)? Let a Wine compiled
with epoll support run on a epoll-less system?

Another question to finish: how do other users of epoll handle all this?

Vincent