Bug#354358: libswt-gtk-3.1-java: Unusable on amd64 (ia32-specific sources used)
May I ask what exactly is preventing this bug from being fixed? As I told two months ago, it seems that the problem is only that upstream's 64-bit sources aren't used by the package on amd64. When I applied the changes between the 32-bit and 64-bit upstream sources to the build tree, everything worked, and has worked now for two months. The only problem is the window closing in azureus 2.4.0.2, but I suspect that is not related to SWT. I see this bug has been tagged upstream, but the upstream sources are just fine, they are just used wrong by the debian package. So what is preventing from including the 64-bit parts in the debian package and closing the bug? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354358: libswt-gtk-3.1-java: Unusable on amd64 (ia32-specific sources used)
On 5/4/06, Lauri Alanko [EMAIL PROTECTED] wrote: May I ask what exactly is preventing this bug from being fixed? As I told two months ago, it seems that the problem is only that upstream's 64-bit sources aren't used by the package on amd64. When I applied the changes between the 32-bit and 64-bit upstream sources to the build tree, everything worked, and has worked now for two months. The only problem is the window closing in azureus 2.4.0.2, but I suspect that is not related to SWT. I see this bug has been tagged upstream, but the upstream sources are just fine, they are just used wrong by the debian package. So what is preventing from including the 64-bit parts in the debian package and closing the bug? Maintaining a package by creating a giant '64-bit' patch by hand for every release does not make a maintainable package. It makes a disaster. The problem is that upstream continues to release one source tarball for 32-bit architectures and a separate source tarball for 64-bit architectures. Neither of these packages contains the ant scripts that they use to create one from the other. For the intents of a Debian maintainer, upstream essentially does not release a source package of SWT *at all*, since it does not contain the necessary scripts to actually build the package. That's why this bug is tagged upstream. Cheers, Shaun
Bug#354358: libswt-gtk-3.1-java: Unusable on amd64 (ia32-specific sources used)
On Thu, May 04, 2006 at 09:19:55AM -0600, Shaun Jackman wrote: For the intents of a Debian maintainer, upstream essentially does not release a source package of SWT *at all*, since it does not contain the necessary scripts to actually build the package. Ah, right. Essentially you're saying that with upstream's current release policy, maintaining a multiplatform package might require surprising amounts of work, and you don't want to take the risk that some future changes will make the maintainer's job a living hell. This is certainly a reasonable stance. However, I think you're overestimating the chances of this happening. Consider: the patch only contains type- and typecode-differences in _generated_ code. If you ever need to do debian-specific patches to generated code, you are screwed already, even if you only package for i386: a new upstream release might introduce changes in the generation process and then your patches wouldn't be usable any longer. So as long as you decide to package for _any_ architecture without having the true sources from upstream, adding further architectures isn't likely to add much to the risk. By the way, have you actually looked at the diff between src.zip contents in the linux-x86 and linux-x86_64 packages? The lines that differ only contain _interface_ specifications: types and names. Unless you plan on adding new functionality, you probably never need to touch these. Bug fixes would only affect actual code, and those parts are not touched by the diff. Incidentally, have you tried out if the x86_64 sources work on 32-bit x86? I don't see why they shouldn't, since the only difference is that the 64-bit sources store native pointers in longs instead of ints. It would yield a performance penalty on 32-bit, but it would allow you to support both x86 and x86_64 from the same sources. Of course, all this mess is Sun's fault. For some completely unfathomable reason, Java and JNI don't provide a primitive type for opaque native pointers, so everyone has to cast them into ints or longs... But thanks for the response. I certainly agree that Eclipse should provide their _real_ sources. Yet even if they don't, it's better to do what we can with what we have... Lauri -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354358: libswt-gtk-3.1-java: Unusable on amd64 (ia32-specific sources used)
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: [0x7f963000,0x7fb63000), sp=0x7fb5ead8, 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.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-amd64-k8-smp
Locale: LANG=C, LC_CTYPE=fi_FI.ISO-8859-1 (charmap=ISO-8859-1)
Versions of packages libswt-gtk-3.1-java depends on:
ii libswt-gtk-3.1-jni3.1-3 Standard Widget Toolkit for GTK JN
libswt-gtk-3.1-java recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354358: libswt-gtk-3.1-java: Unusable on amd64 (ia32-specific sources used)
tag 354358 +confirmed severity 354358 serious retitle 322897 azureus: unusable on AMD64 retitle 331723 azureus: unusable on AMD64 block 322897 on 354358 thanks 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. ...
