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 ---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. Cheers, Shaun 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): > > 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: > > 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 ---
