[ODE] Autotools added to UNSTABLE

Rodrigo Hernandez kwizatz at aeongames.com
Thu Apr 14 09:05:02 MST 2005

Well, the option is to compile OPCODE as a different target, namelly a 
static libOPCODE.a library, but this may become anoying as then you may 
have to link against 2 libraries -lode and -lOPCODE, ode-config may 
handle that, but then some issues may arise when building DLL's in

I think the best thing to do would be to find out a way to pass the 
propper flags to each source file,
I have an idea on how to do it bypasing automake, but I rather use 
automake constructs than dirty hacks, of course the only option may be 
using the hacks, so I better get to the automake manual right now :)

Anyway, if I cant get anything going today I'll just default to -O1


Tanguy Fautre wrote:

> Now that's a tricky choice ;-).
> Because of the code generation bug, OPCODE *must* be compiled with 
> -O1. So if you're going to use the same compilation flags for ODE and 
> OPCODE, you're probably better of with -O1 (although it may 
> significantly slow down ODE :-( ). Otherwise OPCODE will be broken.
> Now if you can specify compilation flag separately for OPCODE and ODE, 
> it may be a nice idea to specify -O1 for OPCODE and -O2 for ODE.
> I'm not sure how big is the performance difference with -O1 vs -O2 for 
> ODE. I don't know ODE enough to know whether the auto-tuned *.c files 
> are going to make ODE slower with -O2 instead of -O1 (used for ODE as 
> a whole).
> As a side note, I think it would be interesting to see how GCC 4.0 
> performs with -O1/O2 on those autotuned *.c files.
> Cheers,
> Tanguy
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode

More information about the ODE mailing list