2005/9/13, Andreas Jochens [EMAIL PROTECTED]:
On 05-Sep-13 15:09, Shaun Jackman wrote:
Does the package actually run and work this way? If so, I'll simply
apply your patch. Although, it is admittedly a bit of a hack.
It _is_ a hack. I did not really check it intensively, but basically the
On Wed, Sep 14, 2005 at 09:18:48AM -0600, Shaun Jackman wrote:
2005/9/13, Andreas Jochens [EMAIL PROTECTED]:
On 05-Sep-13 15:09, Shaun Jackman wrote:
Does the package actually run and work this way? If so, I'll simply
apply your patch. Although, it is admittedly a bit of a hack.
It
2005/9/14, Michael Koch [EMAIL PROTECTED]:
UURGH, NO. This will break SWT on 32 bit archs - if it works on 64 bit archs
at all.
You cannont compare normal C code with JNI C code. JNI C code has much higher
restrictions.
There's that cry of outrage! Hehe. Are there any 32-bit architectures
On Wed, Sep 14, 2005 at 09:52:00AM -0600, Shaun Jackman wrote:
2005/9/14, Michael Koch [EMAIL PROTECTED]:
UURGH, NO. This will break SWT on 32 bit archs - if it works on 64 bit
archs at all.
You cannont compare normal C code with JNI C code. JNI C code has much
higher restrictions.
2005/9/14, Michael Koch [EMAIL PROTECTED]:
You replace jint (which is garanteed to be 32 bit) with long which dont has
this garantee.
Why dont you just build the native sources that upstream supplies for 64 bit
systems?
That is what I do in the eclipse build works very fine. BTW: My Eclipse
On Wed, Sep 14, 2005 at 01:05:50PM -0600, Shaun Jackman wrote:
2005/9/14, Michael Koch [EMAIL PROTECTED]:
You replace jint (which is garanteed to be 32 bit) with long which dont has
this garantee.
Why dont you just build the native sources that upstream supplies for 64
bit systems?
2005/9/14, Michael Koch [EMAIL PROTECTED]:
I just dont get why you wanna patch when upstream has already did the work
for you
and made SWT work on both types of platforms. And changing jint to long can
cause
bugs that are really hard to debug.
Simply because maintaining two source trees
On Wed, Sep 14, 2005 at 01:40:54PM -0600, Shaun Jackman wrote:
2005/9/14, Michael Koch [EMAIL PROTECTED]:
I just dont get why you wanna patch when upstream has already did the work
for you
and made SWT work on both types of platforms. And changing jint to long can
cause
bugs that are
SWT 3.1 does not build on 64 bit platforms due to numerous...
cast from 'void*' to 'jint' loses precision
... errors [1]. The patch to fix this issue would be large, indeed.
I'm inclined to remove the 64 bit platforms from the list of buildable
architectures until this is fixed upstream.
On 05-Sep-13 10:52, Shaun Jackman wrote:
SWT 3.1 does not build on 64 bit platforms due to numerous...
cast from 'void*' to 'jint' loses precision
... errors [1]. The patch to fix this issue would be large, indeed.
I'm inclined to remove the 64 bit platforms from the list of buildable
On Tue, Sep 13, 2005 at 10:52:02AM -0600, Shaun Jackman wrote:
SWT 3.1 does not build on 64 bit platforms due to numerous...
cast from 'void*' to 'jint' loses precision
... errors [1]. The patch to fix this issue would be large, indeed.
Why? Is jint externally defined, or is there some
On Tue, Sep 13, 2005 at 10:52:02AM -0600, Shaun Jackman wrote:
SWT 3.1 does not build on 64 bit platforms due to numerous...
cast from 'void*' to 'jint' loses precision
... errors [1]. The patch to fix this issue would be large, indeed.
I'm inclined to remove the 64 bit platforms from
On 05-Sep-13 19:52, Kurt Roeckx wrote:
Pretty please stop using longs as something that can hold a
pointer. In general you should not cast a pointer to any integer
type. If you really have to, use an intptr_t type.
Believe me, a 'long' will do. There is no architecture where
a 'long' can not
Hello Andreas,
Redefining jint to something else will probably fix the warnings/errors
but it will not work. Every virtual machine for Java on this planet expects
jint to be exact 32 bit. The Java Language Specification mandates this.
This is not changeable.
Cheers,
Michael
--
Escape the Java
On Tue, Sep 13, 2005 at 08:17:39PM +0200, Michael Koch wrote:
SWT generally runs on 64 bit archs. I built my Eclipse packages on amd64.
The problems is that you need to run JNIGeneratorApp on the sources. This
application replaces the integers used normally on 32-bit archs with longs
for
On Tue, Sep 13, 2005 at 10:52:02AM -0600, Shaun Jackman wrote:
The build times out on m68k:
make[1]: Entering directory `/build/buildd/swt-gtk-3.1'
gcj -fPIC -fjni -c `find org -name *.java`
make[1]: *** [java-stamp] Terminated
make: *** [build-stamp] Terminated
Build killed with signal 15
2005/9/13, Michael Koch [EMAIL PROTECTED]:
The problems is that you need to run JNIGeneratorApp on the sources. This
application replaces the integers used normally on 32-bit archs with longs
for 64-bit archs.
...
Perhaps I could run JNIGeneratorApp as part of the build process.
Cheers,
Shaun
2005/9/13, Steve Langasek [EMAIL PROTECTED]:
Which is a pretty lame excuse, because sizeof(long) == 4 on 32-bit archs
(not just Linux but most other platforms as well), and sizeof(long) == 8
on 64-bit archs...
I believe part of the issue is that the width of the type used in the
Java sources
On Tue, Sep 13, 2005 at 03:16:55PM -0600, Shaun Jackman wrote:
2005/9/13, Steve Langasek [EMAIL PROTECTED]:
Which is a pretty lame excuse, because sizeof(long) == 4 on 32-bit archs
(not just Linux but most other platforms as well), and sizeof(long) == 8
on 64-bit archs...
I believe part
On Tue, Sep 13, 2005 at 03:12:07PM -0600, Shaun Jackman wrote:
2005/9/13, Michael Koch [EMAIL PROTECTED]:
The problems is that you need to run JNIGeneratorApp on the sources. This
application replaces the integers used normally on 32-bit archs with longs
for 64-bit archs.
...
Perhaps I
On Tue, Sep 13, 2005 at 12:20:03PM -0700, Steve Langasek wrote:
On Tue, Sep 13, 2005 at 08:17:39PM +0200, Michael Koch wrote:
SWT generally runs on 64 bit archs. I built my Eclipse packages on amd64.
The problems is that you need to run JNIGeneratorApp on the sources. This
application
On Tue, Sep 13, 2005 at 08:46:24PM +0200, Andreas Jochens wrote:
On 05-Sep-13 19:52, Kurt Roeckx wrote:
Pretty please stop using longs as something that can hold a
pointer. In general you should not cast a pointer to any integer
type. If you really have to, use an intptr_t type.
On Wed, Sep 14, 2005 at 12:01:27AM +0200, Kurt Roeckx wrote:
On Tue, Sep 13, 2005 at 08:46:24PM +0200, Andreas Jochens wrote:
On 05-Sep-13 19:52, Kurt Roeckx wrote:
Pretty please stop using longs as something that can hold a
pointer. In general you should not cast a pointer to any
On 05-Sep-14 00:01, Kurt Roeckx wrote:
On Tue, Sep 13, 2005 at 08:46:24PM +0200, Andreas Jochens wrote:
Using 'intptr_t' will lead to problems because older C environments do
not know about it and sometimes 'configure' scripts do ugly things with
'intptr_t'. As an example, 'e2fsprogs'
On 05-Sep-13 15:09, Shaun Jackman wrote:
Does the package actually run and work this way? If so, I'll simply
apply your patch. Although, it is admittedly a bit of a hack.
It _is_ a hack. I did not really check it intensively, but basically the
package seems to work with it. However, a real fix
Package: swt-gtk
Version: 3.0+3.1M4-4
Severity: serious
Hi,
Your package is failing to build on 64 bit arches with the
following error:
g++ -O -DXPCOM_GLUE=1 -DMOZILLA_STRICT_API=1 -fno-rtti -fno-exceptions -Wall
-DSWT_VERSION=3116 -Wno-non-virtual-dtor -fPIC -I. -I/usr/include/mozilla
There have been two releases since 3.1M4, namely 3.1 and 3.2M1. From
Eclipse's download page I see that 3.1 was released for Linux x86_64,
so I suspect these bugs were fixed upstream. So, this should be fixed
once I package SWT 3.1.
Cheers,
Shaun
2005/8/19, Kurt Roeckx [EMAIL PROTECTED]:
27 matches
Mail list logo
