[ODE] GIMPACT on amd64?

[filip]

Hi Dan!

That was an answer to a way old question. ;)

Thanks for clearing this up. I'll look into it when I get back to Ode.
Meanwhile, does anyone know if there are patches for this on their way
to SVN? (I've never submitted a patch for Ode myself. <:) )

Cheers!
/Filip

On Thu, 24 May 2007 05:54:33 -0700
"Daniel Coming" <D at DanielComing.com> wrote:

> Hi Filip,
> 
> The issue lies in the hard coded
> #define GUINT_BIT_COUNT 32
> among other defined constants relying on 32-bit, along with
> #define GINT long
> #define GUINT unsigned long
> Now, if you watch the configure script carefully, on your 64-bit
> machine you'll notice
> checking size of long int... 8
> On a 32-bit machine, both int and long were 32 bit, however newer gcc
> versions are
> giving longs 64 bits. So, the quick fix is to change these two longs
> to ints:
> #define GINT int
> #define GUINT unsigned int
> 
> GImpact still needs to update to 64 bit double precision, but for
> now, this should run.
> 
> Cheers!
> Dan
> 
> On 11/28/06, Filip Joelsson
> <filip at ...<http://www.nabble.com/user/SendEmail.jtp?type=post&post=7638041&i=0>>
> wrote:
> > I'm trying out opende, and I get stuck on every test case that
> > includes a 3d-mesh. As soon as a 3d-mesh is processed by QuickStep
> > I get a segfault in the COMPUTEAABB_FOR_TRIANGLE macro (defined in
> > gim_geometry.h) as called from gim_trimesh_update_aabbset
> > (gim_trimesh.cpp).
> > Stepping through the code with gdb yields two potential error
> > sources: There is a triangle_indices variable which is a (long
> > unsigned int*), and gdb claims that the value of a vertex ptr (v3)
> > has been optimized out.
> 
> > Has anyone gotten *GIMPACT* to work with amd64? Or is it that I use
> > gcc-4.1.1 - and it is overdoing the optimization? I don't have any
> > special CFLAGS set, and I compile with debug enabled. The version is
> > current svn.