Mike Hearn <[EMAIL PROTECTED]> 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 reason
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
Mike Hearn <[EMAIL PROTECTED]> 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
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
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
> So perhaps it would be better to build the RPMs against "pure" installs of
> each distro, from the CDs?
As i think nobody wants buggy systems, this will mean using --force to install
RPMs of old headers. I've never heard of such an update breaking my RPMs so I
won't do any such thing without cons
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
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 i
"Dimitrie O. Paun" <[EMAIL PROTECTED]> 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
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 onl
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
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
On Sun, 21 Nov 2004 15:01:58 -0800, Dan Kegel wrote:
> For the record, I checked, and Red Hat 9's lsb-1.3 package
> simply made ld-lsb.so.1 a symlink to ld-linux.so.2,
I'm pretty sure all distros do that. I've never heard of any LSB compliant
distro using a custom linker to override upstream choic
>> I know Dimi is against it, but that looks like a good thing to do to me.
>
>It's not that I'm against it, I don't much care for the sf.net download page,
>really. If people are willing to work on something that is less confusing,
>by all means, but let's try to not complicate our current downloa
"Shachar Shemesh" <[EMAIL PROTECTED]> 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,
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
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
On Sun, Nov 21, 2004 at 07:31:40PM -0500, Vincent Béron wrote:
> > Or we could just build some download pages for winehq, and just host the
> > files
> > on sf.net, like that we could make them more user friendly. Or we could make
> > some pages and put them on winehq.sf.net, so that packagers cou
Le dim 21/11/2004 à 18:59, Ivan Leo Puoti a écrit :
> >You're forgetting K6 and K6-2 users with i586. Also, RH never provided
> >i586 packages (except for kernel and glibc), so it'd be foreign to the
> >distro to offer only that.
>
> The why not just 386 and 686, that will fit all.
> And you could
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 giv
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 everyb
Dan Kegel wrote:
Bzzt. In the real world, the distro vendor would have noticed
this during LSB certification, and since the shared library
loader for LSB 1.3 is /lib/ld-lsb.so.1 rather than /lib/ld-linux.so.2,
the vendor can easily force libc to be linuxthreads based even
if the default libc is NP
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 invent
>You're forgetting K6 and K6-2 users with i586. Also, RH never provided
>i586 packages (except for kernel and glibc), so it'd be foreign to the
>distro to offer only that.
The why not just 386 and 686, that will fit all.
And you could not build devel and srps packages, or build them but hide them,
Le dim 21/11/2004 à 18:40, Ivan Leo Puoti a écrit :
> > 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...
>
> We already partially have this, if you go to http://www.wine
> 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...
We already partially have this, if you go to http://www.winehq.com/download and
click on Red Hat you get this page
http://
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. Righ
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
Mike Hearn wrote:
I'm not aware of e.g. an LSB-1.3 application that doesn't run properly
on any system that supports LSB-1.3. Are you?
I'm not aware of any LSB applications at all, actually. But let's take
RealPlayer for example. Let's pretend that Real had made it an LSB app.
Would that have save
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 requ
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
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
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
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 inter
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 su
> Correct. When a commonly-needed package becomes "stable",
> a snapshot of its interface specification is taken, and added
> to the LSB. LSB applications can then rely on that
> interface being available. That might sound like a no-op,
> but the painstaking attention to detail involved in naili
Mike Hearn wrote:
> [The LSB] really doesn't deal with anything useful at all that isn't already
> stable and on every Linux system anyway.
Correct. When a commonly-needed package becomes "stable",
a snapshot of its interface specification is taken, and added
to the LSB. LSB applications can then
LSB 3, on the other hand, is going to add Gnome support, so they're
at least thinking about the desktop now.
(Your other objections - FreeType, fontconfig, libjpeg, OpenSSL, etc -
could be packaged along with an LSB implementation of Wine, so they're
not really an issue.)
Forgive the slight shift t
On Sat, 20 Nov 2004 17:09:18 -0800, Dan Kegel wrote:
> LSB 2.0 doesn't deal with sound, scanning, or printing (beyond lpr, anyway?),
It really doesn't deal with anything useful at all that isn't already
stable and on every Linux system anyway.
> so an LSB 2.0 version of Wine would probably have t
"Shachar Shemesh" <[EMAIL PROTECTED]> 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
Dmitry Timoshkov wrote:
"Shachar Shemesh" <[EMAIL PROTECTED]> 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?
"Shachar Shemesh" <[EMAIL PROTECTED]> 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 h
Dmitry Timoshkov wrote:
"Shachar Shemesh" <[EMAIL PROTECTED]> 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, li
Dmitry Timoshkov wrote:
"Shachar Shemesh" <[EMAIL PROTECTED]> 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
"Shachar Shemesh" <[EMAIL PROTECTED]> 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, coll
Mike Hearn wrote:
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.
LSB 2.0 doesn't d
> 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?
Yes, it would be a good idea considering how many packages you build.
> It's a mess, but Wine does some things so close to glibc that
> i
> I count 24 packages
Well, I've got only one RPM that works on Mandrake 9.2, 10.0 and 10.1, and it
runs on 9.1 too if you upgrade your glibc packages, so having fewer packages is
porbably also possible for RH.
Ivan.
Libero ADSL: nav
Hi,
--- Shachar Shemesh <[EMAIL PROTECTED]> 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 cou
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 appro
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 i
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 pe
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
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
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,
> >>
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.linux
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
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 th
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-chewin
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 muc
> 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 loadi
Mike Hearn <[EMAIL PROTECTED]> 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 g
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
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 c
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/questi
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 be
66 matches
Mail list logo
