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 <[EMAIL PROTECTED]> 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
