epoll, LSB (was: Re: Problem roundup)
dank at kegel.com
Sat Nov 20 00:17:40 CST 2004
> 1) The RH9 RPMs are apparently being compiled with epoll support linked
> in. This is causing user pain. We should really be using dlsym here,
> why are we not again?
> glibc is not backwards compatible, the RH9 RPMs should be built
> against the RH9 glibc. There is nothing special about epoll, you can
> have the same issue with any glibc symbol, and we can't start
> dynamically loading them all.
> 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.
Or better yet, ask people to download the right package.
I just downloaded
and it worked fine on RH9.
I wonder, though: the fact that somebody downloaded the wrong
package means there are probably too many different versions
at sourceforge to download. I count 24 packages! (OK, a few of
them are srpms.) Shoot, can't we package Wine as an LSB package?
I suspect Wine depends on nothing that isn't in the LSB.
That'd make life a lot easier for the users... at least for
those whose distros come with LSB support installed by default.
Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
More information about the wine-devel