Re: [Openexr-devel] undefined symbol link error

[Drew Hess]

For dealing with math.h portability issues, we (ILM) use ImathMath.h.

#include ImathMath.h

then use Imath::Math<float>::ceil ()  etc.

Ahh, but I see the problem.  ImathMath.h assumes you've defined 
PLATFORM_DARWIN_PPC.  All of the OpenEXR Makefiles and Visual C++ project 
files do this for you, but that doesn't help when you're using Imath in 
your own projects.

I guess we'll need to add an ImathPlatform.h file, included by all Imath
headers, that defines those things properly for the platform on which
you're compiling.

Scott, as a workaround, try passing -DPLATFORM_DARWIN_PPC to gcc in your 
Project Builder project, that should fix the problem.


-dwh-


 On Thu, 16 Oct 2003, Nafees Bin Zafar wrote:

> I haven't found a nice alternative either.
> 
> #ifdef __APPLE_CC__
> # define ceilf(a)    ceil(a)
> # define floorf(a)   floor(a)
> # define fmodf(a,b)  fmod(a,b)
> # define fabsf(a)    fabs(a)
> 
> # define powf(a,b)   pow(a,b)
> # define expf(a)     exp(a)
> # define logf(a)     log(a)
> # define log10f(a)   log10(a)
> # define sqrtf(a)    sqrt(a)
> 
> # define drand48()   ((double)rand()/RAND_MAX)
> # define srand48(n)  srand((n));
> 
> # define sinf(a)     sin(a)
> # define sinhf(a)    sinh(a)
> # define cosf(a)     cos(a)
> # define coshf(a)    cosh(a)
> # define tanf(a)     tan(a)
> # define tanhf(a)    tanh(a)
> # define asinf(a)    asin(a)
> # define acosf(a)    acos(a)
> # define atanf(a)    atan(a)
> # define atanhf(a)   atanh(a)
> # define atan2f(a,b) atan2(a,b)
> #endif
> 
> 
> 
> -n
> 
> Darrin Cardani wrote:
> 
> > At 8:23 PM -0700 10/15/03, Scott Frankel wrote:
> >
> >> Many of the new errors I'm getting are from undeclared symbols; i.e.:
> >> ::asinf.  They originate in ImathMath.h, included in ImathVec.h.  Is 
> >> there
> >> a lib file that's not getting read properly, where asinf, atanf, &c. 
> >> are declared?
> >
> >
> > The problem is that under OS X, using the apple-supplied libraries, 
> > the trig functions for floats don't exist. Only the double versions 
> > do. You could define your own functions (or even macros) which just 
> > cast the arguments to doubles and call them.
> >
> > I don't know what the reasoning was for getting rid of the float 
> > versions of these functions. It makes it a pain to write AltiVec code 
> > that produces identical results to scalar code, for one thing. I've 
> > read, though I can't prove it, that working with doubles is faster on 
> > PPC than working with single precision floats and that's why they did 
> > it. But I've also read about this happening to others as well.
> >
> > I'm new to using gcc, so I'm sorry to say, I don't know what the 
> > answer is other than my suggestion above.
> >
> > Darrin
> 
> 
> 
>