Your message dated Sat, 25 Feb 2006 11:08:47 -0700
with message-id <[email protected]>
has caused the Debian Bug report #354358,
regarding libswt-gtk-3.1-java: Unusable on amd64 (ia32-specific sources used)
to be marked as having been forwarded to the upstream software
author(s) "Billy Biggs" <[email protected]>.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Re: Bug#354358: libswt-gtk-3.1-java: Unusable on amd64 ia32-specific sources used
Sat, 25 Feb 2006 11:08:47 -0700
The upstream SWT sources in CVS have magic scripts that run through
the Java sources and change ints to longs for 64-bit targets. Since
Java doesn't include a preprocessor or any way to extend the type
system, the developer is left with sed as the only way to implement
necessary basic types like intptr_t. The SWT team release a SWT source
archive, from which Debian's SWT package is built. Unfortunately, it
doesn't include these scripts to support 64-bit architectures.
The patch I accepted for bug #324030 fixes the build on 64-bit
systems, but unfortunately doesn't actually fix the problem, as you've
noticed. So, without any other solution, I am dependent on the
upstream authors to release a SWT source package that includes their
64-bit type system.
On 2/25/06, Lauri Alanko <[email protected]> wrote:
> Package: libswt-gtk-3.1-java
> Version: 3.1-3
> Severity: grave
> Justification: renders package unusable
> Azureus hasn't been working on AMD64 Debian out of the box ever, I think.
> This seems to be why.
> >From a Sun Hotspot 1.5.0_05 error log after a sigsegv when starting
> Stack: [0x00007fffff963000,0x00007fffffb63000), sp=0x00007fffffb5ead8, free
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> C [libc.so.6+0x74ac6]
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j org.eclipse.swt.internal.gtk.OS.memmove([BII)V+0
> j org.eclipse.swt.internal.Converter.wcsToMbcs(Ljava/lang/String;[CZ)[B+60
> Then, from the sources for swt-gtk-3.1.2 (in os.c):
> JNIEXPORT void JNICALL OS_NATIVE(memmove___3BII)
> (JNIEnv *env, jclass that, jbyteArray arg0, jint arg1, jint arg2)
> /* ...... */
> memmove((void *)lparg0, (const void *)arg1, (size_t)arg2);
> /* ...... */
> Obviously treating a 32-bit jint like a 64-bit pointer cannot work.
> It seems that when building the debian package, the same sources are
> being used for both 32-bit and 64-bit architectures although the sources
> are arch-specific:
> Indeed, the os.c in swt-3.1.2-gtk-linux-x86_64.zip (from eclipse.org)
> contains a different version that uses jlongs instead of jints.
> This is essentially the same problem as in bug #324030, of course. It's
> claimed to be fixed, but all I see in xpcom.cpp is a casting hack to get
> rid of compiler errors, but the precision loss is still there. On a
> 64-bit platform you _can't_ store a pointer in a jint, it just won't fit
> no matter what you do. You have to use jlongs and make sure the java
> code calling the native method also uses longs to store pointers. Having
> a separate version that uses ints on 32-bit platforms seems like a
> dubious performance hack.
--- End Message ---