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 > packages are ready > to replace your SWT. When you give me your okay I can imidiately upload it to > the archive > (via some sponsor). I think this would be the easiest solution at all.
I realise that long is not guaranteed to be 32-bit. In fact, that's the very reason I'm using it, so that on 64-bit platforms it will be wide enough to cast a pointer to long. The negative consequence of changing (jint) to (long) is that on 64-bit architectures the pointer will be cast to a 64-bit long, and then silently cast down to a 32-bit jint. This second step is potentially lossy on a system that uses addresses greater than 2^32 (4 GB). Although potentially hazardous, this is how the package has been behaving with GCC 3 for some time. So, I don't believe this patch is a regression, but merely returning the package to status quo. If it's possible to patch one source tree to work on all architectures, I prefer that solution to using one source tree per architecture, which quickly gets out of hand. Cheers, Shaun
