[email protected]
[Top] [All Lists]

Bug#354358: marked as forwarded (libswt-gtk-3.1-java: Unusable on amd64

Subject: Bug#354358: marked as forwarded libswt-gtk-3.1-java: Unusable on amd64 (ia32-specific sources used)
From: Debian Bug Tracking System
Date: Sat, 25 Feb 2006 10:33:28 -0800
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 ---
Subject: Re: Bug#354358: libswt-gtk-3.1-java: Unusable on amd64 ia32-specific sources used
From: "Shaun Jackman"
Date: Sat, 25 Feb 2006 11:08:47 -0700
Hello Lauri,

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
> Azureus:
> Stack: [0x00007fffff963000,0x00007fffffb63000),  sp=0x00007fffffb5ead8,  free 
> space=2030k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
> code)
> 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):
>         (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:
> http://dev.eclipse.org/mhonarc/lists/platform-swt-dev/msg04684.html
> 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 ---
<Prev in Thread] Current Thread [Next in Thread>
  • Bug#354358: marked as forwarded (libswt-gtk-3.1-java: Unusable on amd64 (ia32-specific sources used)), Debian Bug Tracking System <=