Andreas Tille wrote:
> /home/tillea/debian-maintain/packages/arb/arb-0.0.20050506/INCLUDE/awt_canvas.hxx:67:
> error: 'AWT_canvas' has not been declared
> make[2]: *** [AW_preset.o] Error 1
> make[2]: *** Waiting for unfinished jobs
>
>
> I guess it is a really small problem for people with C
Frans Pop wrote:
> Who cares what default it sets or not sets? The point is that it has no
> way to determine the correct encoding for files in the svn repo.
That is not true. For file that have the svn:mime-type property, it
might be possible. For example, if the mime-type indicates it is XML,
t
Joe Wreschnig wrote:
> Which installs ugettext as '_' function into the __builtin__ namespace.
> That makes _ return Python 'unicode' objects, which is what programs
> should be using internally anyway.
>
> This is harder if you're trying to localize a module since then you
> don't want to screw w
Brian Nelson wrote:
> OK, very well then, I'll undo the GCC 4 transition for libaspell15.
Isn't there still a binary-compatibility issue here? I thought that
in an application, there must only be one version of libstdc++,
directly or indirectly. Otherwise, during runtime, symbols may resolve
from
G. C. wrote:
Is there any approach that we can avoid publicizing the third party code
while porting to Linux? Do we need to write some shim layer code in
Linux kernel to interface the third party code? How can we do that? Is
there any document or samples?
In general, this is not possible. It is
Marcelo E. Magallon wrote:
The patch has been already written: http://lwn.net/Articles/8634/ I'm
sure theere's a better link, but that's the best I could extract out of
google without resorting to bribery :-)
This patch is insufficient. It does not implement xaddl.
Regards,
Martin
John Goerzen wrote:
Nobody has even explained WHY we have this issue. The summary posted on the
bug report just said that there is a problem with atomicity.h, not what the
problem is or why it exists.
Just look at the file for yourself. It is easy enough to see: it uses
inline assembly that is on
John Goerzen wrote:
While we're at it, I fail to see the logic of removing support for i386
while we still support m68k.
Because there is a bug that only applies to i386 (see the subject). I
wish everybody would focus on fixing this specific bug. There may be
many good or bad things that can be s
John Goerzen wrote:
As I say this, I'm sure people can say the same about i486 and even i386
machines. Why exactly do we need to remove this support?
Read the bug report with the number you put in your Subject.
Regards,
Martin
Arnd Bergmann <[EMAIL PROTECTED]> writes:
> It would surely be nice to see performance numbers from actual
> applications. After all, the applications are normally doing
> some things besides low level atomic operations.
Indeed, it would be interesting to find out how often applications
invoke th
Morgon Kanter wrote:
Not starting a flamewar here, but in all honesty, who is going to try
to use KDE on a 386 anyway? Actually, while we are on that, who is even
going to try to use X at all on a 386?
Probably nobody will. IMO, it is the worse that the KDE binaries have
to be built for i386 comp
Arnd Bergmann <[EMAIL PROTECTED]> writes:
> a) The patch gets merged upstream. It won't hurt anyone who is
> building i486+ optimized binaries and fixes a real bug.
Upstream won't accept the patch, because of the performance penalty.
Even if upstream accepts the patch, that won't be before
Arnd Bergmann <[EMAIL PROTECTED]> writes:
> No, look at my patch again. If you build without i486 optimization,
> the compiler will see only the extern declaration for
> __exchange_and_add().
I see. What sonames do you suggest to give to the two copies of
libstdc++? You once said you'd call them
Arnd Bergmann <[EMAIL PROTECTED]> writes:
> They have to be compiled for i386, as they have always been.
> If they were compiled for i486, they would not run on i386
> anyway, with or without the bug.
But if they are compiled for i386, they won't run on other Linux
systems, thus losing binary com
Arnd Bergmann <[EMAIL PROTECTED]> writes:
> Right. Any reason why the patch below should not work?
Yes, plenty.
> When __exchange_and_add is an extern function, the implementation
> does not matter to applications using it. Binaries optimized for
> i486 or higher can still use the inline functi
Matthias Urlichs wrote:
Hmm. Did anybody measure the performance increase in a "typical"
userspace-CPU-intensive program when built with i586-only options
(as opposed to "optimize for i586+ but generate compatible code)?
In the current issue, it is not that much a question of performance,
but of co
Lars Wirzenius wrote:
So using a 386 as a router and firewall, which it is perfectly capable
of hardwarewise
Is that really the case?
a) Is anybody actually doing this, today?
b) Do you then have 10MB or 100MB ethernet in that computer?
Can you even put a 100MB ethernet card into the computer?
Andreas Metzler wrote:
Does anybody know how/if other Distributions reacted to this issue?
Suse, Redhat et.al. afaik have been using gcc-3.x for more than one
release.
They just don't support i386 anymore.
http://www.suse.de/en/private/products/suse_linux/i386/system_requirements.html
http://www.re
- Original Message -
From: "Mikael Hedin" <[EMAIL PROTECTED]>
Newsgroups: linux.debian.devel
Sent: Sunday, December 08, 2002 11:00 PM
Subject: [Testing] Why isn't a52dec updating
> I see that the testing scripts are running again. Now I wonder why
> a52dec isn't going in. In update_out
19 matches
Mail list logo
