Hi, I just got pointed at this bug, I am a developer on the SWT
project.
The issue here is that in Java memory we need to store pointers to C
objects. jint is 32 bits, jlong is 64 bits, by the Java spec. To keep
memory use down, we decided to have the Java and C code for 64-bit GTK+
ports be
Shaun Jackman ([EMAIL PROTECTED]):
> I'm building the Debian package from the source distribution src.zip
> in swt-3.1-gtk-linux-x86.zip. This build.xml does not contain a
> replace.32.to.64 target, and neither does
> swt-3.1-gtk-linux-x86_64.zip. There is no org/eclipse/swt/tools
> directory eith
Shaun Jackman ([EMAIL PROTECTED]):
> Keeping SWT and Eclipse in different source packages allows the two
> packages to be maintained independently, which I think is a major
> plus. For one, this allows SWT to be patched without having to rebuild
> Eclipse and vice versa. An autoconf'ed SWT tarbal
Adrian Bunk ([EMAIL PROTECTED]):
> Package: tvtime
> Version: 0.9.15-1
> Severity: serious
>
> ../plugins/greedyh.asm:270: error: unknown register name 'mm7' in 'asm'
This is because of a change in gcc. In version 4, they now require
that you use -mmmx before they acknowledge that MMX registe
Steve Langasek ([EMAIL PROTECTED]):
> The question is, what prevents the inline assembly in question from
> being executed on 486 or non-MMX 586 systems? I didn't see any arch
> checks in the code that would prevent this, but maybe I missed
> something.
Each deinterlacer method has a parameter
Steve Langasek ([EMAIL PROTECTED]):
> > The fix is to delete the MMX registers from the clobbers list, or
> > compile with -mmmx/-msse. I prefer removing them, as using
> > -mmmx/-msse is scary and opens you up to more gcc bugs.
>
> While it's true that using more registers introduces more
> pos
Steve Langasek ([EMAIL PROTECTED]):
> Er, P2 systems support MMX instructions, and PPC systems would never
> have been able to build the inline assembly in question (therefore
> it's clearly not present in any binaries being run on that platform),
> so neither is actually evidence that the runtime
Francesco Poli ([EMAIL PROTECTED]):
> The package copyright file states, in part:
>
> src/speedy.*
> [...] mpeg2 reference implementation copyright [...]
>
> This is a copyright notice with a disclaimer of warranty, but no license at
> all! All rights reserved. Where's the permission to distrib
8 matches
Mail list logo