epoll, LSB (was: Re: Problem roundup)
Mike Hearn:
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?
Alexandre Julliard:
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.
Mike Hearn:
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.
Alexandre Julliard:
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 http://prdownloads.sourceforge.net/wine/wine-20041019-1rh9winehq.i686.rpm 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. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Le sam 20/11/2004 à 01:17, Dan Kegel a écrit : [snip]
Or better yet, ask people to download the right package. I just downloaded http://prdownloads.sourceforge.net/wine/wine-20041019-1rh9winehq.i686.rpm and it worked fine on RH9.
That (wrong package installed) is probably the cause of some problems, right. That's why I often ask the exact filename of the rpm installed.
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.
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. 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. The name and version number of the target is in the rpm filename, so it should be easy to pick the good one. 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? 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). 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). Vincent
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
Mike Hearn wrote:
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.
No, that's not what optimizing does. The instruction set of all CPUs since 386 is virtually identical, and since 486 is almost completely identical. HOWEVER, different internal CPU structure means that the CPUs progressively approach the RISC architecture. One of the characteristics of the RISC architecture is that the compiler is very aware of internal CPU structures, pipeline lengths and bubbles. When you switch on i686 optimization, actual produced instructions would probably not differ much. What would differ is the order in which they are produced. Code optimized for 686 would run on 586 (and probably 486 as well), but not run as fast. I don't know how significant this impact is. Wine is not very CPU intensive. It's just something to keep in mind.
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.
Hmm. Would separating the BiDi code (which is the reason ICU is linked with GDI) into a separate DLL (they way it is on Windows 2000) help? It's something I want to do anyways because: 1. It's how it is on Windows. 2. It would probably allow CrossOver to come with BiDi support. 3. GDI is not the only BiDi consumer. Specifically, DrawText needs to be BiDi aware, as well as the Edit control. This would mean that the same problem would still happen for Israeli and Arabic speaking wine users needing FC3 RPMs, but it would not block everyone.
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.
I hate that solution. I've been bitten by overly strict dependencies before. If you require libstdc++5, mark as depending on it. Same goes for libc versions.
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).
Personally, I think the right way to solve that one is to fix the dependencies in the spec file. I don't see any reason for a RH RPM to install on SUSE and not run. If it installs, it should run. If there are library differences, it shouldn't install, citing the library it needs.
Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
On Sat, 2004-11-20 at 21:33 +0200, Shachar Shemesh wrote:
No, that's not what optimizing does. The instruction set of all CPUs since 386 is virtually identical, and since 486 is almost completely identical. HOWEVER, different internal CPU structure means that the CPUs progressively approach the RISC architecture.
One of the characteristics of the RISC architecture is that the compiler is very aware of internal CPU structures, pipeline lengths and bubbles. When you switch on i686 optimization, actual produced instructions would probably not differ much. What would differ is the order in which they are produced. Code optimized for 686 would run on 586 (and probably 486 as well), but not run as fast.
I don't know how significant this impact is. Wine is not very CPU intensive. It's just something to keep in mind.
Yep, I'm aware of the scheduling optimizations used on super-scalar (sp?) processors. My point was that discussions on the Fedora lists indicated the kernel guys thought scheduling for Athlon would improve things for that chip and not actually hurt the P4 any, so it made sense to compile everything as i586 with Athlon scheduling. Athlon is apparently much more sensitive to compiler scheduling.
Hmm. Would separating the BiDi code (which is the reason ICU is linked with GDI) into a separate DLL (they way it is on Windows 2000) help?
Yes I think that'd be good, as long as things didn't crash and burn if the DLL couldn't be loaded.
I hate that solution. I've been bitten by overly strict dependencies before. If you require libstdc++5, mark as depending on it. Same goes for libc versions.
Makes sense. RPM should have picked it up automatically, I'm not sure why it didn't. thanks -mike -- Mike Hearn <mike(a)navi.cx>
Le sam 20/11/2004 à 14:59, Mike Hearn a écrit : [snip]
I hate that solution. I've been bitten by overly strict dependencies before. If you require libstdc++5, mark as depending on it. Same goes for libc versions.
Makes sense. RPM should have picked it up automatically, I'm not sure why it didn't.
Because it would have caught a whole slew of other dependancies which are not as soft as they could be yet. So instead of getting "why do I need glut to install Wine, and what is glut?" I decided to simply not use the automatic dependancy discovery tool while making the rpms (starting from RH9). Vincent
Hi, --- Shachar Shemesh <wine-devel(a)shemesh.biz> wrote:
Hmm. Would separating the BiDi code (which is the reason ICU is linked with GDI) into a separate DLL (they way it is on Windows 2000) help? It's something I want to do anyways because:
Having it as a DLL would be nice because then I could merge it in to ReactOS with less work. Thanks Steven __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
Hmm. Would separating the BiDi code (which is the reason ICU is linked with GDI) into a separate DLL (they way it is on Windows 2000) help?
We have wine_unicode.dll for that and many things are already separated there, like unicode, case map, collation tables and appropriate algorithms. Eventually we have to implement bi-di support there without relying on any external libraries. -- Dmitry.
Dmitry Timoshkov wrote:
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
Hmm. Would separating the BiDi code (which is the reason ICU is linked with GDI) into a separate DLL (they way it is on Windows 2000) help?
We have wine_unicode.dll
...
Eventually we have to implement bi-di support there without relying on any external libraries.
why? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Dmitry Timoshkov wrote:
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
Hmm. Would separating the BiDi code (which is the reason ICU is linked with GDI) into a separate DLL (they way it is on Windows 2000) help?
We have wine_unicode.dll for that and many things are already separated there, like unicode, case map, collation tables and appropriate algorithms.
After some looking into it, I think this is the wrong place to place BiDi. At the moment, Windows does BiDi (depending on version) at either function level, LPK.DLL or uniscribe. In other words, Windows already have specific locations where BiDi is performed. wine_unicode, on the other hand, is just a helper used internally by wine. The thing we REALLY should do in the long run is implement uniscribe. That's where BiDi really must be.
Eventually we have to implement bi-di support there without relying on any external libraries.
BiDi is a $&!(@*#)$ complicated algorithm (excuse my language). Why on earth should we insist on writing it ourselves? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
Eventually we have to implement bi-di support there without relying on any external libraries.
BiDi is a $&!(@*#)$ complicated algorithm (excuse my language). Why on earth should we insist on writing it ourselves?
We don't really have to write it from scratch, porting an existing code would suffice, but a difference between unicode char width (16 vs. 32 bit) makes it impossible to use any system unicode APIs. Another reason to have an internal implementation is to not depend on possible differences between implementations, differences in collation tables is an obvious example here. -- Dmitry.
Dmitry Timoshkov wrote:
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
Eventually we have to implement bi-di support there without relying on any external libraries.
BiDi is a $&!(@*#)$ complicated algorithm (excuse my language). Why on earth should we insist on writing it ourselves?
We don't really have to write it from scratch, porting an existing code would suffice, but a difference between unicode char width (16 vs. 32 bit) makes it impossible to use any system unicode APIs.
Lost you there. We are currently using ICU precisely because it does have UTF-16 support.
Another reason to have an internal implementation is to not depend on possible differences between implementations, differences in collation tables is an obvious example here.
Lost you there again. There is no dependence of BiDi on collation, or we would use ICU for a lot more than only BiDi. ICU is an entire Unicode solution, and does have all of those things. Seriously, I don't see anyone here volunteering to maintain the BiDi code, and I don't have the resources to chase Unicode around. I really think using an external library is the right thing to do. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
We don't really have to write it from scratch, porting an existing code would suffice, but a difference between unicode char width (16 vs. 32 bit) makes it impossible to use any system unicode APIs.
Lost you there. We are currently using ICU precisely because it does have UTF-16 support.
Another reason to have an internal implementation is to not depend on possible differences between implementations, differences in collation tables is an obvious example here.
Lost you there again. There is no dependence of BiDi on collation, or we would use ICU for a lot more than only BiDi. ICU is an entire Unicode solution, and does have all of those things.
That's my point here: we don't need an external unicode solution, we already have one, we just need to add missing parts, and we really don't want to depened on ICU or anything else.
Seriously, I don't see anyone here volunteering to maintain the BiDi code, and I don't have the resources to chase Unicode around. I really think using an external library is the right thing to do.
I don't understand you: you were arguing some time ago that ICU is too bad as an external library and freebidi is not ready to be used in Wine. Now you want to use that approach anyway. It's really time to rethink your stance and either import an existing bidi code to Wine and use it as a base for further improvements, or find a replacement for ICU and start to use it. String folding, case mapping, character types, collation, decomposition, code page conversions are already implemented in wine_unicode, I don't see why bi-di can't added there as well. If we would think in terms of laziness Wine would be nowhere these days. -- Dmitry.
Dmitry Timoshkov wrote:
That's my point here: we don't need an external unicode solution, we already have one, we just need to add missing parts, and we really don't want to depened on ICU or anything else.
I think the source of the problem is a small misunderstanding about what LPK.DLL does on windows. It's not where the reordering algorithm is. That's in uniscribe. What's there is how this reordering algorithm is used for ExtTextOut, DrawText, EditControl and so on. As such, I think it's best if we did the same in Wine. Since the interface to LPK.DLL is undocumented, I think it's best to use something with similar functionality but different name, say "WINELPK". As for the algorithm itself, I have no objection to it being implemented in wine_unicode. I'm just questioning the wisdom of that DLL. What does Windows use for the same functionality? If it's not there, where is it and why not put it there for wine too? As for the reordering algorithm, that should be implemented in USP10.dll under (ScriptLayout, ScriptStringGetOrder etc.). I don't see anything wrong with Uniscribe depending on ICU for the time being, in any case.
Seriously, I don't see anyone here volunteering to maintain the BiDi code, and I don't have the resources to chase Unicode around. I really think using an external library is the right thing to do.
I don't understand you: you were arguing some time ago that ICU is too bad as an external library and freebidi is not ready to be used in Wine.
Now you want to use that approach anyway. It's really time to rethink your stance and either import an existing bidi code to Wine and use it as a base for further improvements, or find a replacement for ICU and start to use it.
The reasons I stated against ICU are exactly what's haunting us now. It's too big, it depends on the C++ runtime, and you can't dynamically link it. Other than that, it's a great library. I'm just hoping that if another DLL had these problems rather than GDI, end users would suffer less. Particularly if that new DLL was a soft dependency, (as LPK is in Windows, BTW). Fribidi would have been great, if only it supported UTF-16. It doesn't, and adding UTF-16 support is non-trivial. There were structural changes that were meant to take place to make UTF-16 support easier, in which case I was planning on implementing it upstream. It is also easy to dynamically link fribidi. However, these changes are taking their time in happening, so we use ICU for the time being. None of this translates to "we'll write our own". As for taking one of those code's and making them our own, I simply don't see what's there for us to gain. ICU is C++, nothing we can reasonably do will change that. Fribidi is difficult to add UTF-16 support to at the moment, so we gain nothing there too. Writing our own is a headache of magnitudes I don't want to even think of.
String folding, case mapping, character types, collation, decomposition, code page conversions are already implemented in wine_unicode, I don't see why bi-di can't added there as well. If we would think in terms of laziness Wine would be nowhere these days.
Because BiDi already has a well determined place in Windows. That place is uniscribe. Uniscribe does a little of the other things as well, but quite frankly, not much. At least not that I could make out. As such, I vote for implementing stuff where it should be. This also has the extra benefit of making uniscribe the one depending on ICU, not GDI. Assuming GDI's dependence on Uniscribe is through LPK, and that LPK is a soft dependency, this means that users that don't have the right C++ runtime, don't want the extra size, or can't get ICU depending DLLs loaded for whatever other reason will still be able to use Wine (though not Uniscribe, which I think is only fair). Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
I think the source of the problem is a small misunderstanding about what LPK.DLL does on windows. It's not where the reordering algorithm is. That's in uniscribe. What's there is how this reordering algorithm is used for ExtTextOut, DrawText, EditControl and so on. As such, I think it's best if we did the same in Wine. Since the interface to LPK.DLL is undocumented, I think it's best to use something with similar functionality but different name, say "WINELPK".
One of the reasons why Alexandre decided to add unicode support in wine_unicode is that it's completely not documented how it's done in Windows, especially since it's implemented differently in different Windows platforms. It would be plain stupid to create another custom Wine dll while already there is a place for that stuff.
As for the algorithm itself, I have no objection to it being implemented in wine_unicode. I'm just questioning the wisdom of that DLL. What does Windows use for the same functionality? If it's not there, where is it and why not put it there for wine too?
See above.
As for the reordering algorithm, that should be implemented in USP10.dll under (ScriptLayout, ScriptStringGetOrder etc.). I don't see anything wrong with Uniscribe depending on ICU for the time being, in any case.
As soon as you or anybody else implement uniscribe APIs you can start arguing where to place core of it. But still, personally I don't see nothing wrong to implement it in wine_unicode and use that as a backend, as currently done for everything else like FoldString or CompareString.
Fribidi would have been great, if only it supported UTF-16. It doesn't, and adding UTF-16 support is non-trivial. There were structural changes that were meant to take place to make UTF-16 support easier, in which case I was planning on implementing it upstream. It is also easy to dynamically link fribidi. However, these changes are taking their time in happening, so we use ICU for the time being. None of this translates to "we'll write our own".
What do you mean by that? Why adding UTF-16 is not trivial? For the starters we can completely ignore surrogates, and Windows does not have unicode chars above 0xffff anyway. -- Dmitry.
Shachar Shemesh wrote:
I think the source of the problem is a small misunderstanding about what LPK.DLL does on windows. It's not where the reordering algorithm is. That's in uniscribe. What's there is how this reordering algorithm is used for ExtTextOut, DrawText, EditControl and so on. As such, I think it's best if we did the same in Wine. Since the interface to LPK.DLL is undocumented, I think it's best to use something with similar functionality but different name, say "WINELPK".
As for the algorithm itself, I have no objection to it being implemented in wine_unicode. I'm just questioning the wisdom of that DLL. What does Windows use for the same functionality? If it's not there, where is it and why not put it there for wine too?
Windows uses ntdll. We don't want to get rid of wine_unicode because it is also used in wineserver and that obviously cannot use ntdll. Rob
Robert Shearman wrote:
Shachar Shemesh wrote:
I think the source of the problem is a small misunderstanding about what LPK.DLL does on windows. It's not where the reordering algorithm is. That's in uniscribe. What's there is how this reordering algorithm is used for ExtTextOut, DrawText, EditControl and so on. As such, I think it's best if we did the same in Wine. Since the interface to LPK.DLL is undocumented, I think it's best to use something with similar functionality but different name, say "WINELPK".
As for the algorithm itself, I have no objection to it being implemented in wine_unicode. I'm just questioning the wisdom of that DLL. What does Windows use for the same functionality? If it's not there, where is it and why not put it there for wine too?
Windows uses ntdll. We don't want to get rid of wine_unicode because it is also used in wineserver and that obviously cannot use ntdll.
Rob
A very good reason. One that doesn't apply to BiDi, though. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Le sam 20/11/2004 à 13:58, Mike Hearn a écrit : [snip]
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.
I never claimed there's a big speed advantage between the 3 builds. But since I (for myself) prepare the athlon one, and at least the i386 one for everybody else, I may as well prepare the i686 one.
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).
I guess that'd depend on where libICU comes from (and which libstdc++ it's compiled against). AFAIK, libICU is not shipped with FC2 nor FC3, so the libstdc++ version will depend on where it comes from (ie, not under my control). If people begin to mix from 3rd party builds without any thought about the dependancies on their system...
This came to light because a user tried to install the FC2 RPM on FC3 due to lack of FC3 RPMs.
I know, I haven't got around finding time to install it yet. And I have one less video card for yet a couple of days, which makes it a bit more difficult to install it on a second computer while still using my primary one.
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.
What do you propose then? I can't prevent all user mistakes when they choose a filename.
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.
And I'll most probably do it for next release. [snip] Vincent
On Sun, Nov 21, 2004 at 04:38:31PM -0500, Vincent Béron wrote:
I never claimed there's a big speed advantage between the 3 builds. But since I (for myself) prepare the athlon one, and at least the i386 one for everybody else, I may as well prepare the i686 one.
I think this is a problem: we have too many builds, and that's confusing. Let's just have the i386 one (with the Athlon optimizations) and be done with it. The download page is getting crazy, and we get too little benefit from all of these optimizations to justify the (user visible) complexity. Besides, we're still alpha, this type of optimizations are the least of our concerns, really. -- Dimi.
On Sun, Nov 21, 2004 at 05:19:42PM -0500, Dimitrie O. Paun wrote:
On Sun, Nov 21, 2004 at 04:38:31PM -0500, Vincent Béron wrote:
I never claimed there's a big speed advantage between the 3 builds. But since I (for myself) prepare the athlon one, and at least the i386 one for everybody else, I may as well prepare the i686 one.
I think this is a problem: we have too many builds, and that's confusing. Let's just have the i386 one (with the Athlon optimizations) and be done with it. The download page is getting crazy, and we get too little benefit from all of these optimizations to justify the (user visible) complexity.
Besides, we're still alpha, this type of optimizations are the least of our concerns, really.
Definitely. Algorithmic changes (like using epoll ;) are bound to bring way more speedups than silly compiler flags. Ciao, Marcus
Marcus Meissner wrote:
Algorithmic changes (like using epoll ;) are bound to bring way more speedups than silly compiler flags.
epoll reduces wineserver's CPU using when running iTunes from >90% to less than 4%. Try finding a compiler flag that gives that kind of improvement ;-) Mike
Le dim 21/11/2004 à 17:19, Dimitrie O. Paun a écrit :
On Sun, Nov 21, 2004 at 04:38:31PM -0500, Vincent Béron wrote:
I never claimed there's a big speed advantage between the 3 builds. But since I (for myself) prepare the athlon one, and at least the i386 one for everybody else, I may as well prepare the i686 one.
I think this is a problem: we have too many builds, and that's confusing. Let's just have the i386 one (with the Athlon optimizations) and be done with it. The download page is getting crazy, and we get too little benefit from all of these optimizations to justify the (user visible) complexity.
Could we show (our own pages) where users could choose distro, then distro version, then actual package? Instead of pointing them to a few screenful of files directly... Another way to tackle it would be with the distro version not only in the filename but in the release name also (20041019 Fedora Core 2, then underneath it the list of corresponding packages). Other ideas? Vincent
On Sun, Nov 21, 2004 at 05:52:03PM -0500, Vincent Béron wrote:
Another way to tackle it would be with the distro version not only in the filename but in the release name also (20041019 Fedora Core 2, then underneath it the list of corresponding packages).
Other ideas?
Rather then inventing yet another layer of complexity-management, I say we can start by simply dropping the packages thare are not needed. I really don't think we should be publishing Athlon packages for example, even if we have them available. -- Dimi.
Vincent Béron wrote:
Le dim 21/11/2004 à 17:19, Dimitrie O. Paun a écrit :
On Sun, Nov 21, 2004 at 04:38:31PM -0500, Vincent Béron wrote:
I never claimed there's a big speed advantage between the 3 builds. But since I (for myself) prepare the athlon one, and at least the i386 one for everybody else, I may as well prepare the i686 one.
I think this is a problem: we have too many builds, and that's confusing. Let's just have the i386 one (with the Athlon optimizations) and be done with it. The download page is getting crazy, and we get too little benefit from all of these optimizations to justify the (user visible) complexity.
Could we show (our own pages) where users could choose distro, then distro version, then actual package? Instead of pointing them to a few screenful of files directly...
Another way to tackle it would be with the distro version not only in the filename but in the release name also (20041019 Fedora Core 2, then underneath it the list of corresponding packages).
Other ideas?
Vincent
Perhaps a form structure similar to the one used to select download version on Nvidia's website is what you are interested in?
On Sun, 2004-11-21 at 16:38 -0500, Vincent Béron wrote:
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).
I guess that'd depend on where libICU comes from (and which libstdc++ it's compiled against). AFAIK, libICU is not shipped with FC2 nor FC3, so the libstdc++ version will depend on where it comes from (ie, not under my control). If people begin to mix from 3rd party builds without any thought about the dependencies on their system...
Hrm, I thought it came from your system? I mean the RPMs *seem* to include libICU: the gdi DLL is much bigger on disk than my own non-ICU build is, and it depends on libstdc++ which mine doesn't either. You're not building the FC RPMs with ICU?
People choosing the wrong RPM is a very common mistake.
What do you propose then? I can't prevent all user mistakes when they choose a filename.
It's not a very helpful answer right now but long term I'm proposing a single binary package that works for everyone, with distro-specific packages there for those who want them.
And I'll most probably do it for next release.
Cool. thanks -mike -- Mike Hearn <mike(a)navi.cx>
Le dim 21/11/2004 à 17:37, Mike Hearn a écrit :
On Sun, 2004-11-21 at 16:38 -0500, Vincent Béron wrote:
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).
I guess that'd depend on where libICU comes from (and which libstdc++ it's compiled against). AFAIK, libICU is not shipped with FC2 nor FC3, so the libstdc++ version will depend on where it comes from (ie, not under my control). If people begin to mix from 3rd party builds without any thought about the dependencies on their system...
Hrm, I thought it came from your system? I mean the RPMs *seem* to include libICU: the gdi DLL is much bigger on disk than my own non-ICU build is, and it depends on libstdc++ which mine doesn't either. You're not building the FC RPMs with ICU?
Right, a static libICU is included. Too much time spent away from it...
People choosing the wrong RPM is a very common mistake.
What do you propose then? I can't prevent all user mistakes when they choose a filename.
It's not a very helpful answer right now but long term I'm proposing a single binary package that works for everyone, with distro-specific packages there for those who want them.
That'd be great, but which lib versions do you plan to link to (Alsa, OpenSSL, etc.)? How far back do you want to be compatible with? Vincent
On Sun, 2004-11-21 at 17:40 -0500, Vincent Béron wrote:
That'd be great, but which lib versions do you plan to link to (Alsa, OpenSSL, etc.)? How far back do you want to be compatible with?
Good question. Until lots of users stop complaining that it doesn't work on their systems, I guess. Right now apbuild is a bit aggressive w.r.t glibc, we wind the clock back to before Debian Stable which is clearly silly. The delta needs to be recalculated.
From reading online help/newbie forums I've yet to see people using systems older than Red Hat 8, most seem to be at least on RH9 by now. That's still pretty poor compared to MS but hey, it's better than nothing.
Some libs may have broken backwards compatibility since then. Probably have, in fact. That's one reason why I've not done an autopackage yet, distro-neutral binaries are tricky to get right in the face of a very unstable platform. -- Mike Hearn <mike(a)navi.cx>
Sunday, November 21, 2004, 2:38:31 PM, you wrote:
Le sam 20/11/2004 à 13:58, Mike Hearn a écrit : [snip]
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.
I never claimed there's a big speed advantage between the 3 builds. But since I (for myself) prepare the athlon one, and at least the i386 one for everybody else, I may as well prepare the i686 one.
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).
I guess that'd depend on where libICU comes from (and which libstdc++ it's compiled against). AFAIK, libICU is not shipped with FC2 nor FC3, so the libstdc++ version will depend on where it comes from (ie, not under my control). If people begin to mix from 3rd party builds without any thought about the dependancies on their system...
This came to light because a user tried to install the FC2 RPM on FC3 due to lack of FC3 RPMs.
I know, I haven't got around finding time to install it yet. And I have one less video card for yet a couple of days, which makes it a bit more difficult to install it on a second computer while still using my primary one.
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.
What do you propose then? I can't prevent all user mistakes when they choose a filename.
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.
And I'll most probably do it for next release.
[snip]
Vincent
On Fri, 19 Nov 2004 22:17:40 -0800, Dan Kegel wrote:
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.)
That's typical for open source Linux projects. It's a stupid mess. There *could* only be one package, if Linux was an actual platform and not merely a series of random binary snapshots pretending to be something stable.
Shoot, can't we package Wine as an LSB package?
No, that's really not possible/sensible.
I suspect Wine depends on nothing that isn't in the LSB.
I suspect it depends on a lot, for instance FreeType, OpenSSL, CUPS, fontconfig, libasound/arts/jack, SANE, libjpeg etc etc.
That'd make life a lot easier for the users... at least for those whose distros come with LSB support installed by default.
The LSB is a waste of time for desktop apps (which Wine is) and will continue to be so until either major management/scope changes are made to the project or some seriously large amounts of manpower are dumped into it. Even then the LSB would be a pale shadow of what we need to be competitive with Windows, as this is really a community-wide mentality problem not a structural/logistical problem. You could compare it to the usability issues the open source community was blissfully ignorant of up until a few years ago. A GNOME/HIG style educational push will be required to make distro-neutral binary packaging truly viable/reliable. It's more likely that a different platform/base project will come along and usurp it (at least in the desktop space) to be quite honest. Until then I'll continue recommending we hack around epoll style problems and work towards having distro-neutral binary packages distributed alongside the RPMs on SourceForge. Autopackage when it's stable is one possibility, Loki Setup is used in CrossOver and that works quite well too although it's rather old now (and some users can't always figure out how to run it). There are probably other possibilities I'm not aware of. thanks -mike
participants (12)
-
Adam Babcock -
Dan Kegel -
Dimitrie O. Paun -
Dmitry Timoshkov -
Marcus Meissner -
Mike Hearn -
Mike McCormack -
Robert Shearman -
Shachar Shemesh -
Steven Edwards -
Vincent Béron -
Vitaliy Margolen