Go Language Binding

[tshannon]

I've been looking for a physics engine, with a C-API, and was excited to learn that Newton has gone open source.

It looks like the header file is C, which means I should be able to create a binding through Go's CGO command (http://golang.org/cmd/cgo/).

However, I'm getting some build errors like this:

Code: Select all

/usr/local/lib/libNewton.so: undefined reference to `__pow_finite'
/usr/local/lib/libNewton.so: undefined reference to `operator delete(void*)'
/usr/local/lib/libNewton.so: undefined reference to `dgMeshEffect::CreateConvexApproximation(float, int) const'
/usr/local/lib/libNewton.so: undefined reference to `__cxa_pure_virtual'
/usr/local/lib/libNewton.so: undefined reference to `__gxx_personality_v0'
/usr/local/lib/libNewton.so: undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
/usr/local/lib/libNewton.so: undefined reference to `vtable for __cxxabiv1::__class_type_info'
/usr/local/lib/libNewton.so: undefined reference to `std::terminate()'
/usr/local/lib/libNewton.so: undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info'
collect2: ld returned 1 exit status

The undefined reference to operator delete(void*) makes me think that the library wouldn't be able to be linked with a C compiler.

Has anyone linked with Newton and built using a C compiler?

[carli2]

There are only few versions in the svn that compile under linux. Since Julio does not write commit messages, you have to search the svn history for changes to the makefiles to find versions that compile under linux.

[tshannon]

Yeah, I can't get the svn version to build at all.

In this case I'm actually using the 2.36 download. After adding a missing folder, the makefile seemed to build the project properly.

I wonder if my issue is related to this:

http://newtondynamics.com/forum/viewtopic.php?f=12&t=6730

[tshannon]

yeah, so it looks like the SVN revisions don't build that often on Linux.

If I'm building a library around this, should I be targeting 200 instead of 300? Everything I've seen in the forms say to use 300, but it doesn't appear to be all that stable.

How much of an API change will there be between 200 and 300?

[carli2]

yeah, so it looks like the SVN revisions don't build that often on Linux.

If I'm building a library around this, should I be targeting 200 instead of 300? Everything I've seen in the forms say to use 300, but it doesn't appear to be all that stable.

Not of you don't have legacy code.
Search for a version of 3.00 that compiles under linux. (And tell me the number, then I can try that, too; or wait until Julio fixed the builds)

How much of an API change will there be between 200 and 300?

It's not much, but it's not fully compatible.

[Julio Jerez]

you are new using teh engine. you sodul use version 300.
It has buin bui with linu more often. try that and see what error you get.

for the must part the Linux problems hapens when I add a new file to the project that the Linux make file do not have.

there is also a Cmake that some one contribute, maybe you can try that

[tshannon]

Should we be building with the cmake files:
.. from the root folder

Code: Select all

mkdir build
cd build
cmake ../
make


or using the makefiles in the projects folder?

The cmake generated makefiles seems to be missing some flags for sse and mmx, as those are the errors I get there.

The makefiles in the project folder seem to have the right flags, as they are actually erroring on syntax issues.

Code: Select all

gcc -c -Wall -Wno-strict-aliasing -D_POSIX_VER -m32 -O2 -fpic -g -msse -msse2 -mfpmath=sse -ffloat-store -ffast-math -freciprocal-math -funsafe-math-optimizations -fsingle-precision-constant -I../../source/core -I../../source/physics -I../../source/meshUtil -o ../../source/physics/dgBody.o ../../source/physics/dgBody.cpp
../../source/physics/dgBody.cpp: In constructor �dgBody::dgBody(dgWorld*, const dgTree<const dgCollision*, int>*, OnBodyDeserialize, dgDeserialize, void*)�:
../../source/physics/dgBody.cpp:110:12: error: �_ASSERT� was not declared in this scope
../../source/physics/dgBody.cpp: In member function �virtual void dgBody::Serialize(const dgTree<int, const dgCollision*>*, OnBodySerialize, dgSerialize, void*)�:
../../source/physics/dgBody.cpp:177:12: error: �_ASSERT� was not declared in this scope
make: *** [../../source/physics/dgBody.o] Error 1
../../source/physics/dgBody.cpp: In constructor âdgBody::dgBody(dgWorld*, const dgTree<const dgCollision*, int>*, OnBodyDeserialize, dgDeserialize, void*)â:
../../source/physics/dgBody.cpp:110:12: error: â_ASSERTâ was not declared in this scope
../../source/physics/dgBody.cpp: In member function âvirtual void dgBody::Serialize(const dgTree<int, const dgCollision*>*, OnBodySerialize, dgSerialize, void*)â:
../../source/physics/dgBody.cpp:177:12: error: â_ASSERTâ was not declared in this scope



[tshannon]

FYI, just did an SVN update this morning and I've gotten it to build on a 32 bit linux build using makefile in the posix32 project folder.

it's rev 2522

[Julio Jerez]

synk again to SVN, I fix all teh error in the Linux make file, they compile and build out of the Box now.

sorry about that, I work on visual studio for long time and once in a while I update the Posix make files.
Must of teh time is mostlly adding new files and fixing some syntax discreapncy beteeen GCC and Visual studio.
In fact buidl with GCC make the code more rubust since it is by far a more strict compile that MSVS

[tshannon]

Everything's building fine, and I got the library to link properly with CGO, so I can now succesfully call Newton from Go code.

I'm not sure if this applies to anyone else, but basically if anyone calls newton from a c based compiler (like cgo), you'll want to include the LDFLAG -lstdc++ (at least on linux) to get it to compile.

Thanks for the fixes. I now have a target to build against.

[tshannon]

I should note that there was a small issue with the Newton.h file.

I believe the NewtonTaperedCylinderParam and NewtonTaperedCapsuleParam need to be typedef'd around line 119, or else my compile shows them as undeclared:

Code: Select all

 115         typedef struct NewtonBoxParam NewtonBoxParam;
 116         typedef struct NewtonConeParam NewtonConeParam;
 117         typedef struct NewtonSphereParam NewtonSphereParam;
 118         typedef struct NewtonCapsuleParam NewtonCapsuleParam;
 119         typedef struct NewtonCylinderParam NewtonCylinderParam;
 120         typedef struct NewtonTaperedCapsuleParam NewtonTaperedCapsuleParam;
 121         typedef struct NewtonTaperedCylinderParam NewtonTaperedCylinderParam;
 122         typedef struct NewtonConvexHullParam NewtonConvexHullParam;
 123         typedef struct NewtonCollisionTreeParam NewtonCollisionTreeParam;
 124         typedef struct NewtonDeformableMeshParam NewtonDeformableMeshParam;
 125         typedef struct NewtonSceneCollisionParam NewtonSceneCollisionParam;
 126         typedef struct NewtonChamferCylinderParam NewtonTaparedCylinderParam;
 127         typedef struct NewtonChamferCylinderParam NewtonChamferCylinderParam;
 128         typedef struct NewtonCompoundCollisionParam NewtonCompoundCollisionParam;
 129         typedef struct NewtonHeightFieldCollisionParam NewtonHeightFieldCollisionParam;


[Julio Jerez]

Ha, Ok I will do that tonioght. those are new shape for core 300, and I forget to add those definitions.
Thanks

[tshannon]

Just another heads up.

The 32bit version builds fine, but I'm getting errors with the 64 bit one.

First, lines 147 and 148 (under the Newton AI section) are uncommented in the 32bit makefile, but commented out in the 64bit one.

Second, after making that change I can build most of the library, but I"m getting the following error:

Code: Select all

gcc -c -Wall -Wno-strict-aliasing -D_POSIX_VER -O2 -fpic -g -msse -msse2 -mfpmath=sse -ffloat-store -ffast-math -freciprocal-math -funsafe-math-optimizations -fsingle-precision-constant -I../../source/core -I../../source/physics -I../../source/meshUtil -I../../source/openCL -I../../source/ai/  -o ../../source/core/dgTypes.o ../../source/core/dgTypes.cpp
../../source/core/dgTypes.cpp: Assembler messages:
../../source/core/dgTypes.cpp:171: Error: invalid instruction suffix for `push'
../../source/core/dgTypes.cpp:174: Error: invalid instruction suffix for `pop'


Looks like there's some sections specifically added for 64 bit cpu, which would explain why I can build fine on 32bit.

If the Issue tracker in googlecode is better for this sort of thing, let me know.
Thanks,

[Julio Jerez]

is this a linux build that you are using these defines

#if (defined (_POSIX_VER) || defined (_MINGW_32_VER) || defined (_MINGW_64_VER))
#ifndef _POSIX_VER_64
#endif

that code is only for detecting CPU type on unix like platforms, I will be glad if ther is a standrd wat to do that, but I do not know how in Linux