ode binaries for OSX and Windows

[Danny Price]

Getting ODE to build is a common problem. I struggled to build it on a windows 7 PC last night with mingw and msis (no VisualStudio) and didn't get far. I've now used my work PC to get the latest SVN and have built the libraries in VS2008.

I also have builds for OSX 10.6 (should work with 10.7 - I haven't upgraded yet).

I'm happy to make these binaries (and the demos) available to anyone who wants them - is there somewhere I can upload them?

[Oleh Derevenko]

Hi

 

What's exactly wrong with building with MinGW on Windows?

===============================================

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

 

H:\Projects\XXXX\other\QNX\lib\ode\trunk>svn up
Updating '.':

 

Fetching external item into 'ou':
External at revision 37.

 

At revision 1860.

 

H:\Projects\XXXX\other\QNX\lib\ode\trunk>cd build

 

H:\Projects\XXXX\other\QNX\lib\ode\trunk\build>premake4.exe --with-ou --with-libccd --with-demos --with-tests gmake
Building configurations...
Running action 'gmake'...
Generating gmake/Makefile...
Generating gmake/demo_boxstack.make...
Generating gmake/demo_buggy.make...
Generating gmake/demo_cards.make...
Generating gmake/demo_chain1.make...
Generating gmake/demo_chain2.make...
Generating gmake/demo_collision.make...
Generating gmake/demo_crash.make...
Generating gmake/demo_cylvssphere.make...
Generating gmake/demo_feedback.make...
Generating gmake/demo_friction.make...
Generating gmake/demo_gyroscopic.make...
Generating gmake/demo_heightfield.make...
Generating gmake/demo_hinge.make...
Generating gmake/demo_I.make...
Generating gmake/demo_jointPR.make...
Generating gmake/demo_jointPU.make...
Generating gmake/demo_joints.make...
Generating gmake/demo_kinematic.make...
Generating gmake/demo_motion.make...
Generating gmake/demo_motor.make...
Generating gmake/demo_ode.make...
Generating gmake/demo_piston.make...
Generating gmake/demo_plane2d.make...
Generating gmake/demo_slider.make...
Generating gmake/demo_space.make...
Generating gmake/demo_space_stress.make...
Generating gmake/demo_step.make...
Generating gmake/demo_basket.make...
Generating gmake/demo_cyl.make...
Generating gmake/demo_moving_trimesh.make...
Generating gmake/demo_trimesh.make...
Generating gmake/demo_tracks.make...
Generating gmake/ode.make...
Generating gmake/drawstuff.make...
Generating gmake/tests.make...
Done.

 

H:\Projects\XXXX\other\QNX\lib\ode\trunk\build>cmd /c c:\batch\make1.cmd
starting gnu make utility
mingw32-make.exe: *** No targets specified and no makefile found.  Stop.

 

H:\Projects\XXXX\other\QNX\lib\ode\trunk\build>cd gmake

 

H:\Projects\XXXX\other\QNX\lib\ode\trunk\build\gmake>cmd /c c:\batch\make1.cmd
starting gnu make utility
==== Building ode ====
Creating ../../lib/DebugSingleDLL
Creating obj/DebugSingleDLL/ode
amotor.cpp
ball.cpp
contact.cpp
fixed.cpp
hinge.cpp
hinge2.cpp
joint.cpp
lmotor.cpp
null.cpp
piston.cpp
plane2d.cpp
pr.cpp
pu.cpp
slider.cpp
universal.cpp
fastdot.c
fastldlt.c
fastlsolve.c
fastltsolve.c
nextafterf.c
array.cpp
box.cpp
capsule.cpp
collision_cylinder_box.cpp
collision_cylinder_plane.cpp
collision_cylinder_sphere.cpp
collision_cylinder_trimesh.cpp
collision_kernel.cpp
collision_libccd.cpp
collision_quadtreespace.cpp
collision_sapspace.cpp
collision_space.cpp
collision_transform.cpp
collision_trimesh_box.cpp
collision_trimesh_ccylinder.cpp
collision_trimesh_disabled.cpp
collision_trimesh_distance.cpp
collision_trimesh_gimpact.cpp
collision_trimesh_opcode.cpp
collision_trimesh_plane.cpp
collision_trimesh_ray.cpp
collision_trimesh_sphere.cpp
collision_trimesh_trimesh.cpp
collision_trimesh_trimesh_new.cpp
collision_util.cpp
convex.cpp
cylinder.cpp
error.cpp
export-dif.cpp
heightfield.cpp
lcp.cpp
mass.cpp
mat.cpp
matrix.cpp
memory.cpp
misc.cpp
objects.cpp
obstack.cpp
ode.cpp
odeinit.cpp
odemath.cpp
odeou.cpp
odetls.cpp
plane.cpp
quickstep.cpp
ray.cpp
rotation.cpp
sphere.cpp
step.cpp
threading_base.cpp
threading_impl.cpp
timer.cpp
util.cpp
Opcode.cpp
OPC_AABBCollider.cpp
OPC_AABBTree.cpp
OPC_BaseModel.cpp
OPC_Collider.cpp
OPC_Common.cpp
OPC_HybridModel.cpp
OPC_LSSCollider.cpp
OPC_MeshInterface.cpp
OPC_Model.cpp
OPC_OBBCollider.cpp
OPC_OptimizedTree.cpp
OPC_Picking.cpp
OPC_PlanesCollider.cpp
OPC_RayCollider.cpp
OPC_SphereCollider.cpp
OPC_TreeBuilders.cpp
OPC_TreeCollider.cpp
OPC_VolumeCollider.cpp
StdAfx.cpp
IceAABB.cpp
IceContainer.cpp
IceHPoint.cpp
IceIndexedTriangle.cpp
IceMatrix3x3.cpp
IceMatrix4x4.cpp
IceOBB.cpp
IcePlane.cpp
IcePoint.cpp
IceRandom.cpp
IceRay.cpp
IceRevisitedRadix.cpp
IceSegment.cpp
IceTriangle.cpp
IceUtils.cpp
atomic.cpp
customization.cpp
malloc.cpp
threadlocalstorage.cpp
outest.cpp
alloc.c
ccd.c
mpr.c
polytope.c
support.c
vec3.c
Linking ode
Creating library file: ../../lib/DebugSingleDLL/libode_singled.a
==== Building drawstuff ====
Creating obj/DebugSingleDLL/drawstuff
drawstuff.cpp
windows.cpp
resources.rc
Linking drawstuff
Creating library file: ../../lib/DebugSingleDLL/libdrawstuffd.a
==== Building demo_boxstack ====
Creating obj/DebugSingleDLL/demo_boxstack
demo_boxstack.cpp
resources.rc
Linking demo_boxstack
==== Building demo_buggy ====
Creating obj/DebugSingleDLL/demo_buggy
demo_buggy.cpp
resources.rc
Linking demo_buggy
==== Building demo_cards ====
Creating obj/DebugSingleDLL/demo_cards
demo_cards.cpp
resources.rc
Linking demo_cards
==== Building demo_chain1 ====
Creating obj/DebugSingleDLL/demo_chain1
demo_chain1.c
resources.rc
Linking demo_chain1
==== Building demo_chain2 ====
Creating obj/DebugSingleDLL/demo_chain2
demo_chain2.cpp
resources.rc
Linking demo_chain2
==== Building demo_collision ====
Creating obj/DebugSingleDLL/demo_collision
demo_collision.cpp
resources.rc
Linking demo_collision
==== Building demo_crash ====
Creating obj/DebugSingleDLL/demo_crash
demo_crash.cpp
resources.rc
Linking demo_crash
==== Building demo_cylvssphere ====
Creating obj/DebugSingleDLL/demo_cylvssphere
demo_cylvssphere.cpp
resources.rc
Linking demo_cylvssphere
==== Building demo_feedback ====
Creating obj/DebugSingleDLL/demo_feedback
demo_feedback.cpp
resources.rc
Linking demo_feedback
==== Building demo_friction ====
Creating obj/DebugSingleDLL/demo_friction
demo_friction.cpp
resources.rc
Linking demo_friction
==== Building demo_gyroscopic ====
Creating obj/DebugSingleDLL/demo_gyroscopic
demo_gyroscopic.cpp
resources.rc
Linking demo_gyroscopic
==== Building demo_heightfield ====
Creating obj/DebugSingleDLL/demo_heightfield
demo_heightfield.cpp
resources.rc
Linking demo_heightfield
==== Building demo_hinge ====
Creating obj/DebugSingleDLL/demo_hinge
demo_hinge.cpp
resources.rc
Linking demo_hinge
==== Building demo_I ====
Creating obj/DebugSingleDLL/demo_I
demo_I.cpp
resources.rc
Linking demo_I
==== Building demo_jointPR ====
Creating obj/DebugSingleDLL/demo_jointPR
demo_jointPR.cpp
resources.rc
Linking demo_jointPR
==== Building demo_jointPU ====
Creating obj/DebugSingleDLL/demo_jointPU
demo_jointPU.cpp
resources.rc
Linking demo_jointPU
==== Building demo_joints ====
Creating obj/DebugSingleDLL/demo_joints
demo_joints.cpp
resources.rc
Linking demo_joints
==== Building demo_kinematic ====
Creating obj/DebugSingleDLL/demo_kinematic
demo_kinematic.cpp
resources.rc
Linking demo_kinematic
==== Building demo_motion ====
Creating obj/DebugSingleDLL/demo_motion
demo_motion.cpp
resources.rc
Linking demo_motion
==== Building demo_motor ====
Creating obj/DebugSingleDLL/demo_motor
demo_motor.cpp
resources.rc
Linking demo_motor
==== Building demo_ode ====
Creating obj/DebugSingleDLL/demo_ode
demo_ode.cpp
resources.rc
Linking demo_ode
==== Building demo_piston ====
Creating obj/DebugSingleDLL/demo_piston
demo_piston.cpp
resources.rc
Linking demo_piston
==== Building demo_plane2d ====
Creating obj/DebugSingleDLL/demo_plane2d
demo_plane2d.cpp
resources.rc
Linking demo_plane2d
==== Building demo_slider ====
Creating obj/DebugSingleDLL/demo_slider
demo_slider.cpp
resources.rc
Linking demo_slider
==== Building demo_space ====
Creating obj/DebugSingleDLL/demo_space
demo_space.cpp
resources.rc
Linking demo_space
==== Building demo_space_stress ====
Creating obj/DebugSingleDLL/demo_space_stress
demo_space_stress.cpp
resources.rc
Linking demo_space_stress
==== Building demo_step ====
Creating obj/DebugSingleDLL/demo_step
demo_step.cpp
resources.rc
Linking demo_step
==== Building demo_basket ====
Creating obj/DebugSingleDLL/demo_basket
demo_basket.cpp
resources.rc
Linking demo_basket
==== Building demo_cyl ====
Creating obj/DebugSingleDLL/demo_cyl
demo_cyl.cpp
resources.rc
Linking demo_cyl
==== Building demo_moving_trimesh ====
Creating obj/DebugSingleDLL/demo_moving_trimesh
demo_moving_trimesh.cpp
resources.rc
Linking demo_moving_trimesh
==== Building demo_trimesh ====
Creating obj/DebugSingleDLL/demo_trimesh
demo_trimesh.cpp
resources.rc
Linking demo_trimesh
==== Building demo_tracks ====
Creating obj/DebugSingleDLL/demo_tracks
demo_tracks.cpp
resources.rc
Linking demo_tracks
==== Building tests ====
Creating obj/DebugSingleDLL/tests
collision.cpp
joint.cpp
main.cpp
odemath.cpp
ball.cpp
fixed.cpp
hinge.cpp
hinge2.cpp
piston.cpp
pr.cpp
pu.cpp
slider.cpp
universal.cpp
AssertException.cpp
Checks.cpp
DeferredTestReporter.cpp
DeferredTestResult.cpp
MemoryOutStream.cpp
ReportAssert.cpp
Test.cpp
TestDetails.cpp
TestList.cpp
TestReporter.cpp
TestReporterStdout.cpp
TestResults.cpp
TestRunner.cpp
TimeConstraint.cpp
XmlTestReporter.cpp
TimeHelpers.cpp
Linking tests
Running post-build commands
..\..\lib\DebugSingleDLL\tests
../../tests/joints/universal.cpp(722): error: Failure in test_Universal_Initialization: Expected -2.99435 +/- 0.0001 but was -2.99422
../../tests/joints/universal.cpp(722): error: Failure in test_Universal_Initialization: Expected 32.9944 +/- 0.0001 but was 32.9942
FAILURE: 1 out of 210 tests failed (2 failures).
Test time: 0.25 seconds.
mingw32-make.exe[1]: *** [../../lib/DebugSingleDLL/tests.exe] Error 2
mingw32-make.exe: *** [tests] Error 2

 

H:\Projects\XXXX\other\QNX\lib\ode\trunk\build\gmake>type c:\batch\make1.cmd
@echo off
::set GCC_PATH=C:\util\gcc
set GCC_PATH=C:\util\MinGW
set PATH=%GCC_PATH%\bin;%GCC_PATH%\local\bin;%PATH%
set INCLUDE=%GCC_PATH%\include;%GCC_PATH%\local\include;%GCC_PATH%\mingw32\include;%GCC_PATH%\include\win32
set LIB_SAVE=%LIB%
set LIB=%GCC_PATH%\lib;%GCC_PATH%\local\lib;%GCC_PATH%\mingw32\lib;%GCC_PATH%\lib\win32
set CC=gcc
set LINK=gcc
echo starting gnu make utility
mingw32-make.exe "INCLUDE=%INCLUDE%" "LIB=%LIB%" "CC=gcc" "CXX=g++" "LINK=gcc" %*
set LIB=%LIB_SAVE%
set LIB_SAVE=
exit
H:\Projects\XXXX\other\QNX\lib\ode\trunk\build\gmake>

===============================================

Oleh Derevenko
-- Skype with underscore

 

 

--
You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-...@googlegroups.com.
To unsubscribe from this group, send email to ode-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

[Danny Price]

Can you provide exact instructions for what you did and installed? I'm running Win7 64bit with mingw32 (not sure if that's 64bit capable). I also installed msys out of desperation to provide a unix-like command line and to autogen.

It built boxstack and basket but then failed with loads of errors (looked like OPCODE and Ice, whatever that is).

There was an issue where gnumake couldn't find libstdc++ which required hacking of some files.

It also produced .a and .la files, not the .lib files I was expecting..

Point is it didn't work and the out of date documentation advises you to use VS which I didn't have.

And a quick browse of the email archives for this list shows how common build problems are. It's been said that you don't care about correcting non-critical issues. Providing binaries will allow people to get on with their work instead of messing about with BS like this. Other projects like AntTweakBar and GLFW provide binaries.

[Bill Sellers]

> Running post-build commands
> ..\..\lib\DebugSingleDLL\tests
> ../../tests/joints/universal.cpp(722): error: Failure in test_Universal_Initialization: Expected -2.99435 +/- 0.0001 but was -2.99422
> ../../tests/joints/universal.cpp(722): error: Failure in test_Universal_Initialization: Expected 32.9944 +/- 0.0001 but was 32.9942
> FAILURE: 1 out of 210 tests failed (2 failures).
> Test time: 0.25 seconds.
> mingw32-make.exe[1]: *** [../../lib/DebugSingleDLL/tests.exe] Error 2
> mingw32-make.exe: *** [tests] Error 2
>

Are you talking about the numerical discrepancies here? I wouldn't worry about them too much for single precision results. There's nothing magical about 0.0001 as an error threshold and changing this tolerance to 0.0002 would fix this error. I imagine it is all to do with the floating point flags used for the compile. I always use -fast_math for performance on g++ but it does affect precision in certain situations. VC uses different flags and will give different answers. It's interesting (but sadly unsurprising) that g++ on other Intel platforms such as MacOSX gives different results.

mingw is actually a very useful port for ODE for those of us who use Qt. It means that you can compile your code on Windows without installing anything other than the Qt developers kit which saves quite a bit of time and aggravation.

Cheers
Bill

[Oleh Derevenko]

Just download MinGW and install it with setup that's included with it.

I included content of my make script at the end off the output (did you read that carefully till the end?). It is necessary to define environment variables to point to MinGW's includes and libraries since usually they do not exist at all or point to respective folders of Visual Studio (which will not work, of course).

 

 

 

It built boxstack and basket but then failed with loads of errors (looked like OPCODE and Ice, whatever that is).

There was an issue where gnumake couldn't find libstdc++ which required hacking of some files.

It also produced .a and .la files, not the .lib files I was expecting..

Well, *.a are fine for using with g++ of MinGW. This is what one is expected to get. You will not be able to use those static libraries with Visual Studio anyway. You can use DLLs at most.

 

 

Point is it didn't work and the out of date documentation advises you to use VS which I didn't have.

And a quick browse of the email archives for this list shows how common build problems are. It's been said that you don't care about correcting non-critical issues. Providing binaries will allow people to get on with their work instead of messing about with BS like this. Other projects like AntTweakBar and GLFW provide binaries.

 

Oleh Derevenko
-- Skype with underscore

[Danny Price]

mingw is actually a very useful port for ODE for those of us who use Qt. It means that you can compile your code on Windows without installing anything other than the Qt developers kit which saves quite a bit of time and aggravation.

Cheers
Bill

 

Yes exactly I'm a Qt developer and I use QtCreator.

[Danny Price]

Just download MinGW and install it with setup that's included with it.

I included content of my make script at the end off the output (did you read that carefully till the end?). It is necessary to define environment variables to point to MinGW's includes and libraries since usually they do not exist at all or point to respective folders of Visual Studio (which will not work, of course).

 

Give me some credit Oleh. I build a lot of open source projects and ODE is ALWAYS a pain in the arse.

I noticed you used premake4.exe - I thought this was building VS solutions? Again I don't have VS (or the MS SDK) installed.

 

Well, *.a are fine for using with g++ of MinGW. This is what one is expected to get. You will not be able to use those static libraries with Visual Studio anyway. You can use DLLs at most.

I am well aware of name mangling. I just didn't expect mingw to give me unix library extensions.

[Oleh Derevenko]

premake4.exe is for anything on Windows. It builds project files/makefiles both for Visual Studio and GMake. Run "premake4.exe --help" for details.

 

Oleh Derevenko
-- Skype with underscore

 

 

----- Original Message -----

From: Danny Price

To: ode-...@googlegroups.com

Sent: 3 лютого 2012 р. 13:41

Subject: Re: [ode-users] ode binaries for OSX and Windows

[Danny Price]

Thanks but that's not what the install.txt says:

"1. BUILDING WITH VISUAL STUDIO (2002 and up)

 If you downloaded this source code from Subversion you must first use

 the Premake build system to generate project files.

 Open a command prompt and enter into the build directory. Then run the

 premake4.exe program with the appropriate options to generate the

 project files." (emphasis mine - project implying vcproj files)

It assumes you're only using VisualStudio on Windows. I'll give this a try tonight - as you pointed out, I HAVE to build the libs with mingw as the VS2008 ones will be useless in a mingw build.

[Oleh Derevenko]

Never trust manuals more than help text built in executables. ;-)

Oleh Derevenko
-- Skype with underscore

 

 

----- Original Message -----

From: Danny Price

To: ode-...@googlegroups.com

Sent: 3 лютого 2012 р. 13:49

Subject: Re: [ode-users] ode binaries for OSX and Windows

[Danny Price]

As you've said many times, developers have better things to do.

[Oleh Derevenko]

Also, you made a logical mistake.

The section is named "BUILDING WITH VISUAL STUDIO (2002 and up)". And the fact that premake4 is to be used for building project files for Visual Studio does not imply that it can't also be used for something else like building makefiles for MinGW. ;-)

[Danny Price]

Btw the OSX configuration in premake4.lua for OSX is extremely old (still linking carbon libs). It won't work on anything newer than Leopard.

[Danny Price]

Oleh I'm not going to argue with you. 

For everyone else, I will make the binaries (Windows VS2008 and Mingw, Mac OSX 10.6/7) available once I have them on my website.

2012/2/3 Oleh Derevenko <Oleh.De...@eleks.com>

[Oleh Derevenko]

I'm not arguing. :-) I'm just trying to make a joke of that. :-)

[Danny Price]

Are there ANY planes to release a new snapshot? 0.11.1 is positively ancient now. 

2012/2/3 Oleh Derevenko <Oleh.De...@eleks.com>

[Oleh Derevenko]

This question is to be sent to Daniel and other guys who administrate the project. I don't have control over that.

As my personal contribution I could only build with MinGW x86, any VS (2005 and higher) x86/x64 and for QNX 6.3.0/6.5.0 (if anybody is interested in that).

 

However prebuilt binaries is a questionable thing. You need to make at least following configurations for each platform:
1) 32-bit vs 64-bit

2) With exceptions vs without exceptions.

3) With Opcode vs with GImpact

That gives 8 binaries at least (I omitted other options like inclusion of libccd and libou since they should be included everywhere by default).

Now multiply that by number of platforms (Windows, any UNIXes/Linuxes, any MacOSes). And for all those platforms it would be good to make sure that compiler options were chosen correctly (since minor discrepancies, like using -ffast-math can make simulations unstable).

[Oleh Derevenko]

Well, I have forgotten to add

 

4) With floats vs with doubles.

which gives 16 binaries per OS.

[Danny Price]

That's the worst case. I'm only building for Windows and Mac because on linux, the ODE build system works a lot better.

I'm not sure why anyone would want single-precision builds. That seems like a hold over from game consoles. I don't think it's relevant anymore.

Mac is exclusively 64bit now so that removes another configuration.

With exceptions vs without exceptions? If you're not using C++ exceptions by now then you deserve to build this thing manually.

QNX? I doubt anyone is seriously using ODE for RT development anymore. If they are, they probably need to make other build adjustments.

2012/2/3 Oleh Derevenko <Oleh.De...@eleks.com>

[Oleh Derevenko]

----- Original Message -----

From: Danny Price

To: ode-...@googlegroups.com

Sent: 3 лютого 2012 р. 14:30

Subject: Re: [ode-users] ode binaries for OSX and Windows

 

I'm not sure why anyone would want single-precision builds. That seems like a hold over from game consoles. I don't think it's relevant anymore.

 

 

Single precision is used to decrease amount of data with trimeshes. Memory is a relatively slow resource and it reaaly matters if you can fit your working data set into CPU cache or not.

 

Mac is exclusively 64bit now so that removes another configuration.

 

So, anybody who does not have latest Mac is off the boat?

 

With exceptions vs without exceptions? If you're not using C++ exceptions by now then you deserve to build this thing manually.

With and without exceptions was already discussed here long ago. That's a holywar nobody can win. Exceptions make code much heavier and I personally do not use them in the project.

 

 

 

QNX? I doubt anyone is seriously using ODE for RT development anymore. If they are, they probably need to make other build adjustments.

 

Well, I do. :-D

Other that having RT capabilities, QNX is just a regular OS like any other. And possibility to have processes in RT does not force you to resign from having a simulation running at lower priority.

[Danny Price]

Single precision is used to decrease amount of data with trimeshes. Memory is a relatively slow resource and it reaaly matters if you can fit your working data set into CPU cache or not.

 

Good luck trying to get stable trimesh collisions with single precision! Seriously RAM is cheap. I'd rather get on with my work. 

 

Mac is exclusively 64bit now so that removes another configuration.

So, anybody who does not have latest Mac is off the boat?

Apple haven't produced a 32-bit intel machine since 2006 and even those were low end (Core Solo Mac minis and first gen Core Duo MBPs). Mac users tend to upgrade regularly.

 

With exceptions vs without exceptions? If you're not using C++ exceptions by now then you deserve to build this thing manually.

With and without exceptions was already discussed here long ago. That's a holywar nobody can win. Exceptions make code much heavier and I personally do not use them in the project.

I'm confused - this is ODE we're talking about. It has a C++ core and a C interface which cannot, by it's nature, emit exceptions. Is this flag used to turn on internal exceptions? Whether or not the end user chooses to use exceptions in their code is irrelevant.

Also exceptions are core to C++. Deal with it.

 

QNX? I doubt anyone is seriously using ODE for RT development anymore. If they are, they probably need to make other build adjustments.

 

Well, I do. :-D

Other that having RT capabilities, QNX is just a regular OS like any other. And possibility to have processes in RT does not force you to resign from having a simulation running at lower priority.

Then you're in the minority.

 

Typical open source projects provide binaries with common configurations to get people up and running. Until recently, Qt provided full VS2008, mingw and Mac cocoa and carbon binaries. This is standard practice - you want people to use your code, not mess about with build settings.

[Oleh Derevenko]

----- Original Message -----

From: Danny Price

To: ode-...@googlegroups.com

Sent: 3 лютого 2012 р. 15:14

Subject: Re: [ode-users] ode binaries for OSX and Windows

 

I'm confused - this is ODE we're talking about. It has a C++ core and a C interface which cannot, by it's nature, emit exceptions. Is this flag used to turn on internal exceptions? Whether or not the end user chooses to use exceptions in their code is irrelevant.

 

It affects the code generaled internally in ODE. Actually ODE does not handle exceptions and is not written with exception awareness in mind but COMPILER DOES NOT KNOW THAT. It must anyway generate exception unwinding code with any function call for any local object instances. And even though public interface is pure C, if ODE internals will throw an exception (e.g. from libc on memory allocation failure) it will get out of ODE to the host code. And similarly, if host code raises an exception in any of callbacks from ODE that exception will come back out of the original function that was called in ODE in the first hand.

So the reason for compiling ODE without exceptions are:

1) Why do I need that extra unwinding code if I don't throw exceptions and if that code is not going to achieve its intended purpose due to defective ODE code design anyway?
2) Why must I fear unexpected exceptions coming out of ODE at any time?

[Danny Price]

If you're not using stl (why?) then the only exception client code will likely get will be std::bad_alloc from new. It's typically accepted that you shouldn't try to handle this - if you're out of memory there's little you can do.

You're right in that there is a cost in generating the exception unwinding mechanism. In this case for, why no just turn off exceptions by default if ODE doesn't throw any of it's own? It doesn't effect client code, particularly if ODE is built as a DLL.

2) Why must I fear unexpected exceptions coming out of ODE at any time?

Because it's a cornerstone of C++ design. Exceptions should ONLY be thrown for exceptional conditions, not as a replacement for error codes or assertions. In the vast majority of cases, you should not expect to handle them or attempt to handle them. They simply provide a way to abort out of a stack of procedures that doesn't require complex ifs, gotos and other logic.

[Oleh Derevenko]

Well, on Windows you are also likely to get Access Violation, Stack Overflow, Numeric Division by Zero, Math Operation Faults - all in form of exception.

Oleh Derevenko
-- Skype with underscore

 

 

----- Original Message -----

From: Danny Price

To: ode-...@googlegroups.com

Sent: 3 лютого 2012 р. 15:58

Subject: Re: [ode-users] ode binaries for OSX and Windows

[Danny Price]

On Fri, Feb 3, 2012 at 2:04 PM, Oleh Derevenko <Oleh.De...@eleks.com> wrote:

Well, on Windows you are also likely to get Access Violation, Stack Overflow, Numeric Division by Zero, Math Operation Faults - all in form of exception.

Those are *NOT* C++ exceptions! They are Windows CRT assertions and have nothing to do with C++. They're the Windows equivelant of SIGSEGV etc.

While it is possible to 'catch' them, they don't unwind the stack and are generally fatal unlike real exceptions.

[Oleh Derevenko]

Do you think so? In my opinion that is depended on compilation options and those exceptions can normally be caught and handled just like exceptions thrown by user code. It is not really necessary to terminate application just because the negative argument passed to logarithm or code attempted to read from NULL pointer.

Oleh Derevenko
-- Skype with underscore

 

 

----- Original Message -----

From: Danny Price

To: ode-...@googlegroups.com

Sent: 3 лютого 2012 р. 16:07

Subject: Re: [ode-users] ode binaries for OSX and Windows

--

[Danny Price]

C/C++ doesn't define what should happen when you access a *hanging* pointer so venders came up with their own systems. Unix uses segment faults. The classic mac used 'traps' and Windows uses CRT 'exceptions'. See

http://msdn.microsoft.com/en-us/library/s58ftw19(v=vs.80).aspx 

These are language extensions that you CANNOT turn off. They're part of the host runtime.

The only programs that should attempt to handle these are mission critical drivers, the operating system etc.

C++ exceptions were added to standardize this behavior. Think of them like this:

FunctionA calls FunctionB which calls FunctionC. Later on, FunctionC is changed to allocate memory. If this was C and the call to malloc et al fails, there is no way to communicate that failure up to FunctionA without using a OS extension (like a segfault) or an exit(-1) which will terminate the process. 

Alternatively you could rewrite all three functions so that the failure in FunctionC could be passed back up to FunctionA with return codes. Imagine all the ifs, gotos and checks that would require!

Now in C++, FunctionC can throw a single exception and nothing else needs to change. The 'client' code calling FunctionA can choose to catch this exception or do nothing at all. You don't have to re-write everything to handle it. The exception handling is no-longer mixed with the business logic.

Add to this RAII behavior and class destructors and C++ allows you to produce some very robust code. Suddenly C looks very crummy indeed.

Don't misunderstand me. I like C a lot. But there's a lot of FUD surrounding it's features because they're not well understood.

[Daniel K. O.]

On 02/03/2012 08:34 AM, Oleh Derevenko wrote:
> ODE does not
> handle exceptions and is not written with exception awareness in mind

Just quoted that to emphasize. There is no code inside ODE to recover
from an exception thrown, say, from the collision callback. You could
end up with just half of your bodies/geoms updated, as ODE operations
are not commit/rollback.

You can throw all exceptions you want in the application, just don't do
it from a callback being called by ODE.

--
Daniel K. O.

[Oleh Derevenko]

Thank you for your time spent on this lecture, but I'm in software development since times of Windows 3.11 and I know what structured exception handling (SEH) is. :)

 

Notwithstanding all the arguments below, when I run the following console program...

 

=============================
#include "stdafx.h"

 

struct CMiracle
{
 CMiracle() { printf("Nothing special. I'm being constructed.\n"); }
 ~CMiracle() { printf("A miracle! I'm being destroyed!\n"); }
};

 

int _tmain(int argc, _TCHAR* argv[])
{
 while (true)
 {
  try
  {
   CMiracle m;

 

   *(int *)NULL = 0;
  }
  catch (...)
  {
   printf("OOPS! Exception! ;)\n");
  }

 

 }

 

 return 0;
}

=============================

 

...in my Visual Studio I get...

=============================

Nothing special. I'm being constructed.
A miracle! I'm being destroyed!
OOPS! Exception! ;)
Nothing special. I'm being constructed.
A miracle! I'm being destroyed!
OOPS! Exception! ;)
Nothing special. I'm being constructed.
A miracle! I'm being destroyed!
OOPS! Exception! ;)
Nothing special. I'm being constructed.
A miracle! I'm being destroyed!
OOPS! Exception! ;)
Nothing special. I'm being constructed.
A miracle! I'm being destroyed!
OOPS! Exception! ;)
Nothing special. I'm being constructed.
A miracle! I'm being destroyed!
OOPS! Exception! ;)
Nothing special. I'm being constructed.
A miracle! I'm being destroyed!
OOPS! Exception! ;)
Nothing special. I'm being constructed.
A miracle! I'm being destroyed!
OOPS! Exception! ;)
Nothing special. I'm being constructed.
A miracle! I'm being destroyed!
OOPS! Exception! ;)
Nothing special. I'm being constructed.
A miracle! I'm being destroyed!
OOPS! Exception! ;)
Nothing special. I'm being constructed.
A miracle! I'm being destroyed!
OOPS! Exception! ;)
Nothing special. I'm being constructed.
A miracle! I'm being destroyed!
OOPS! Exception! ;)
Nothing special. I'm being constructed.
A miracle! I'm being destroyed!
OOPS! Exception! ;)
Nothing special. I'm being constructed.
A miracle! I'm being destroyed!
OOPS! Exception! ;)

... and so on ...

=============================

 

Does modern computer science have any explanation for this phenonemon?

[Danny Price]

That's not a standard behavior - there is no C++ exception for dereferencing a null pointer. In fact I just tried that exact code in in VS2008 and got an access violation on the first derefence which is what I would expect. The catch should not be invoked in this case.

[Oleh Derevenko]

That's good you actually tried to compile. :)

Now please recall that I told this is compiler options dependent. So, go to Project Properties and in "Configuration Preferences->C/C++->Code Generation->Enable C++ Exceptions" select "Yes With SEH Exceptions (/EHa)". :)

I know, you don't have that on Linuxes and Macs, but Windows is like this and you have to consider this possibility.

[Danny Price]

Ok. If you're actively developing ODE, you may want to have these 'exceptions' turned on for debugging reasons (although in five years as a windows dev, I've never had the need). But for the rest of us who just want use ODE in project, they can be turned off which is what I will be doing.

[Oleh Derevenko]

Hi Danny,

 

I'm not sure if there is any use for OSX configuration in premake4 (I did not look at MacOSes for ages but I doubt they now can run Windows executables or Windows tools can cross-compile for MacOS) but if you know how to upgrade that configuration to latest trends and how to make any use of it - you are wellcome to provide a patch and I'll integrate it.

Oleh Derevenko
-- Skype with underscore

 

 

----- Original Message -----

From: Danny Price

To: ode-...@googlegroups.com

Sent: 3 лютого 2012 р. 13:58

Subject: Re: [ode-users] ode binaries for OSX and Windows