Hi, So, trolling linuxquestions.org reveals the following top 3 problems users are having with Wine currently: 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? 2) Our bestest bestest friends over at InstallShield Corp have released a new version of their elegant and simple product, which refuses to start with builtin DCOM. 3) Some people still seem to be getting the "C:\\Windows\\System does not exist" message. thanks -mike
Le ven 19/11/2004 à 09:02, Mike Hearn a écrit :
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?
If you're talking about this thread (http://www.linuxquestions.org/questions/showthread.php?s=&threadid=252670), then I didn't reproduce it on my RH9 setup when I released 20041019 (I have a video card fan problem right now, so the video card in that computer is now in my main computer, so I can't test it just right now). I guess the user have a different kernel/glibc than I do (I'm using RH9+updates from RH for RH9+updates from FedoraLegacy for RH9 as of the releases of Wine). The epoll detection/support is not very robust yet it seems. (Slightly OT: would autopackage help here?) Also, PICOspark mentions he gets the same error in WineX, which I personnally find a bit strange. Vincent
On Fri, 2004-11-19 at 16:07, Vincent Béron wrote:
If you're talking about this thread (http://www.linuxquestions.org/questions/showthread.php?s=&threadid=252670), then I didn't reproduce it on my RH9 setup when I released 20041019 (I have a video card fan problem right now, so the video card in that computer is now in my main computer, so I can't test it just right now). I guess the user have a different kernel/glibc than I do (I'm using RH9+updates from RH for RH9+updates from FedoraLegacy for RH9 as of the releases of Wine). The epoll detection/support is not very robust yet it seems.
Hmm, OK. Actually there are several threads, just search for epoll_create on the forums. As long as you're aware of the issue I'm happy. We should really be dynamically detecting this at runtime not compile time.
(Slightly OT: would autopackage help here?)
Well, maybe. The ethos of autopackage is "build once, install anywhere" so before packaging Wine as an autopackage I'd have done the work to make this dynamically loaded. Features enabled at compile time not runtime are e.v.i.l and should generally by regarded as bugs IMHO. The RPM ethos is the exact opposite: "build many, install once". But the issue here is with Wine rather than the actual packaging technology in use.
Also, PICOspark mentions he gets the same error in WineX, which I personnally find a bit strange.
That is a bit bizarre, I just checked and TG CVS appears to use standard poll not epoll. But who knows what their binaries use. thanks -mike
Mike Hearn wrote:
On Fri, 2004-11-19 at 16:07, Vincent Béron wrote:
If you're talking about this thread (http://www.linuxquestions.org/questions/showthread.php?s=&threadid=252670), then I didn't reproduce it on my RH9 setup when I released 20041019 (I have a video card fan problem right now, so the video card in that computer is now in my main computer, so I can't test it just right now). I guess the user have a different kernel/glibc than I do (I'm using RH9+updates from RH for RH9+updates from FedoraLegacy for RH9 as of the releases of Wine). The epoll detection/support is not very robust yet it seems.
Hmm, OK. Actually there are several threads, just search for epoll_create on the forums. As long as you're aware of the issue I'm happy.
We should really be dynamically detecting this at runtime not compile time.
(Slightly OT: would autopackage help here?)
Well, maybe. The ethos of autopackage is "build once, install anywhere" so before packaging Wine as an autopackage I'd have done the work to make this dynamically loaded. Features enabled at compile time not runtime are e.v.i.l and should generally by regarded as bugs IMHO. The RPM ethos is the exact opposite: "build many, install once".
But the issue here is with Wine rather than the actual packaging technology in use.
Also, PICOspark mentions he gets the same error in WineX, which I personnally find a bit strange.
That is a bit bizarre, I just checked and TG CVS appears to use standard poll not epoll. But who knows what their binaries use.
Cedega does not use epoll anywhere. We've cut out most of the poll cost through using Shared Memory so it's not as much of a bottleneck. Ciao, Peter
thanks -mike
Vincent Béron wrote:
Le ven 19/11/2004 à 09:02, Mike Hearn a écrit :
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?
If you're talking about this thread (http://www.linuxquestions.org/questions/showthread.php?s=&threadid=252670), then I didn't reproduce it on my RH9 setup when I released 20041019 (I have a video card fan problem right now, so the video card in that computer is now in my main computer, so I can't test it just right now). I guess the user have a different kernel/glibc than I do (I'm using RH9+updates from RH for RH9+updates from FedoraLegacy for RH9 as of the releases of Wine). The epoll detection/support is not very robust yet it seems.
It's not that. The problem seems to be that RH updated their glibc major version number. Maybe you need to create a dependency in the RPM for a specific glibc version (>=2.3?). That's the reason my original epoll patch was using syscall, btw. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Le sam 20/11/2004 à 08:45, Shachar Shemesh a écrit :
Vincent Béron wrote:
Le ven 19/11/2004 à 09:02, Mike Hearn a écrit :
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?
If you're talking about this thread (http://www.linuxquestions.org/questions/showthread.php?s=&threadid=252670), then I didn't reproduce it on my RH9 setup when I released 20041019 (I have a video card fan problem right now, so the video card in that computer is now in my main computer, so I can't test it just right now). I guess the user have a different kernel/glibc than I do (I'm using RH9+updates from RH for RH9+updates from FedoraLegacy for RH9 as of the releases of Wine). The epoll detection/support is not very robust yet it seems.
It's not that. The problem seems to be that RH updated their glibc major version number. Maybe you need to create a dependency in the RPM for a specific glibc version (>=2.3?). That's the reason my original epoll patch was using syscall, btw.
I remember a glibc update on RH8 which broke binary compatibility for Wine between before and after the update, but not a similar thing for RH9. Original RH9 glibc is glibc-2.3.2-11.9 ( http://mirrors.kernel.org/redhat/redhat/linux/9/en/os/i386/RedHat/RPMS/glibc...). Last update from RH is glibc-2.3.2-27.9.7 (http://mirrors.kernel.org/redhat/redhat/linux/updates/9/en/os/i386/glibc-2.3...). FedoraLegacy hasn't issued an update to glibc for RH9 yet. Looks like the same major version number to me (before downloading and examining the packages)... Vincent
Mike Hearn <mike(a)navi.cx> writes:
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. -- Alexandre Julliard julliard(a)winehq.org
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.
Mike Hearn <mike(a)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. -- Alexandre Julliard julliard(a)winehq.org
On Fri, 19 Nov 2004 21:07:02 +0100, Alexandre Julliard wrote:
I think it's much better to ask packagers to build their packages correctly, it will cause much less trouble in the long run.
Oh well, I guess this is the crux of the disagreement. I don't consider having to have a string-and-chewing-gum ancient distro around to build binaries that work anywhere a good plan and am willing to hack around upstream glibc sillyness, whereas you'd rather people have VMs and such in order to build RPMs each month. To be honest I think both views make sense. Thanks to the total lack of documentation on what the different symvers actually do hacking around this stuff will always be a bit risky. On the other hand, it's an awful lot of work for packagers to do, and as the current problems show easy to mess up.
Le ven 19/11/2004 à 15:07, Alexandre Julliard a écrit :
Mike Hearn <mike(a)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 haven't had time to investigate the issue at hand yet, but I know that RPM did work here launching notepad and building .wine via wineprefixcreate. Somebody posted on wine-devel with the same problem, we'll see what could be the cause. Vincent
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(a)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
On Mon, Nov 22, 2004 at 09:39:32PM -0500, Vincent Béron wrote:
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?
No, please don't specify a glibc version-release. The real fix here is to have Wine compiled with epoll support run on a system without epoll. In fact, RH did not break binary compatibility. They just added a feature in a binary compatible way. We are to blame for making it a such a hard dependency. Windows BTW keeps adding functions all the time, it's just that apps are careful to programmatically link to them so they can run on older versions as well. We should be doing that too. -- Dimi.
"Dimitrie O. Paun" <dpaun(a)rogers.com> writes:
No, please don't specify a glibc version-release. The real fix here is to have Wine compiled with epoll support run on a system without epoll.
No, that's only fixing a symptom. glibc simply doesn't support running on an older version than what it was compiled against; the problem is not limited to epoll, it can potentially happen with any symbol. The right way to build a package that runs on both old and new glibcs is to build it against the old one, anything else is asking for trouble. -- Alexandre Julliard julliard(a)winehq.org
On Tue, 23 Nov 2004 12:13:22 +0100, Alexandre Julliard wrote:
No, that's only fixing a symptom. glibc simply doesn't support running on an older version than what it was compiled against; the problem is not limited to epoll, it can potentially happen with any symbol. The right way to build a package that runs on both old and new glibcs is to build it against the old one, anything else is asking for trouble.
... or bypassing glibc oddness entirely and using syscalls to work around it, as we do in a few other places in the source. I think that was discussed before and rejected though.
Vincent Béron wrote:
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.
Had only that been the case. The newer glibc has the "epoll" symbols, but if you try to invoke them, they'll always return "not implemented". It's one of the weirdest moves by RedHat I've seen.
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.)?
Probably not.
Let a Wine compiled with epoll support run on a epoll-less system?
I tried that in my original patch. That approach was rejected.
Another question to finish: how do other users of epoll handle all this?
Use libevent? Sorry, couldn't resist :-)
Vincent
Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Le mar 23/11/2004 à 02:41, Shachar Shemesh a écrit :
Vincent Béron wrote:
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.
Had only that been the case. The newer glibc has the "epoll" symbols, but if you try to invoke them, they'll always return "not implemented". It's one of the weirdest moves by RedHat I've seen.
Then why do we link to them if they simply return "not implemented"? As notepad works corectly with the newer glibc, I wonder if we do have a fallback to the poll branch (I thought it was a compile-time define). Vincent
On Tue, 23 Nov 2004 19:48:41 -0500, Vincent Béron wrote:
Then why do we link to them if they simply return "not implemented"? As notepad works corectly with the newer glibc, I wonder if we do have a fallback to the poll branch (I thought it was a compile-time define).
Alexandre seems to feel we should always use glibc support when available even if that support is just "return -ENOSYS". I'm not really sure why but I expect there's a good reason for it.
Mike Hearn <mike(a)navi.cx> writes:
On Tue, 23 Nov 2004 19:48:41 -0500, Vincent Béron wrote:
Then why do we link to them if they simply return "not implemented"? As notepad works corectly with the newer glibc, I wonder if we do have a fallback to the poll branch (I thought it was a compile-time define).
Alexandre seems to feel we should always use glibc support when available even if that support is just "return -ENOSYS". I'm not really sure why but I expect there's a good reason for it.
We cannot check for a "return -ENOSYS" function at compile time, so if the function exists we link to it and check for ENOSYS at run time, and fall back to poll() in that case. -- Alexandre Julliard julliard(a)winehq.org
On Wed, 2004-11-24 at 16:18 +0100, Alexandre Julliard wrote:
We cannot check for a "return -ENOSYS" function at compile time, so if the function exists we link to it and check for ENOSYS at run time, and fall back to poll() in that case.
Right, but why not always use syscalls and never glibc? I think that is what Vincent was getting at. I think you did say that it was a general principle to always use libc when possible but I don't remember if you explained why. thanks -mike
Mike Hearn <mike(a)navi.cx> writes:
Right, but why not always use syscalls and never glibc? I think that is what Vincent was getting at. I think you did say that it was a general principle to always use libc when possible but I don't remember if you explained why.
There are many reasons, for instance it works on all CPUs, it can take advantage of various glibc improvements (like faster syscalls) or bug fixes, it supports linker tricks like LD_PRELOAD, if someday FreeBSD adopts the epoll interface it will work there as well, etc. -- Alexandre Julliard julliard(a)winehq.org
On Mon, 22 Nov 2004 21:39:32 -0500, Vincent Béron wrote:
I'm 99% positive that the problem is: users didn't update their distribution.
That is a bad problem but should not surprise us. The volume and size of updates shipped by Red Hat/Fedora is typically so large that dialup users especially in developing countries cannot keep up. Even in the UK when I was on dialup I frequently skipped large updates I didn't feel were necessary. This is especially true of very large packages like glibc, kdelibs, openoffice etc. So perhaps it would be better to build the RPMs against "pure" installs of each distro, from the CDs?
participants (6)
-
Alexandre Julliard -
Dimitrie O. Paun -
Mike Hearn -
Peter Hunnisett -
Shachar Shemesh -
Vincent Béron