Re: [Openexr-devel] ImathTest failures

[Paul Schneider]

Hi, Darrin,

I haven't tried building Windows targets in CodeWarrior, but I can't 
think of any reason why it shouldn't work.  I assume you've modified 
the prefix file so that the right macros are defined for building on 
Windows?  You should just have to replace PLATFORM_DARWIN_PPC with 
PLATFORM_WIN32.  HAVE_IOS_BASE and friends should probably be defined 
for the Mac build as well.

One thing that might be biting you is that some of the OpenEXR code 
might assume that PLATFORM_WIN32 means you're compiling with Visual 
C++, so turning on this symbol might enable some nasty tricks that we 
use to get VC to accept our (perfectly legal C++) code.  Anything like 
this should be testing for the presence of the MS compiler (_MSC_VER) 
instead.  If you spot any problems like this, let us know, and we'll 
fix it up - we want to keep this code as portable as possible.

And yes, we're using our own routines like floor() etc in the Imath 
namespace, for speed and compatibility, and we want to keep using 
those.  I'm not sure why Imath::floor seems to be generating incorrect 
code on Windows.  Since the Metrowerks Windows compiler uses the same 
front end as the Mac compiler, it must be a problem in the x86 backend. 
 Does the test pass if you build without optimizations?  Is there any 
way you can test it with CodeWarrior Pro 9?

To answer some other questions (hopefully without rekindling a platform 
war), we do provide both CodeWarrior and gcc projects (aka Makefiles) 
for building OpenEXR on OS X.  The CodeWarrior projects are a separate 
module in CVS; the Makefiles in the main distribution work with gcc on 
OS X as well as gcc Linux and most default C compilers on most flavors 
of Unix.  It's trivial to link the gcc-created libraries into an Xcode 
project - gcc is the compiler Xcode uses.  You just drag the built 
libraries into your project and set up your include paths 
appropriately.  We could provide PB and/or Xcode projects to generate 
the same libraries, but that would just be more maintenance for us, and 
not much benefit to developers.  I do have a sample Xcode project that 
shows how to use the gcc-built libs in an Xcode project (and how to 
call the OpenEXR C++ API from Objective-C++) that I've been thinking 
about posting for awhile - I should probably get around to that.  But, 
we already support the two most widely-used development systems on OS 
X.  There are lots of good reasons for using CodeWarrior - one is that 
you might need to generate CFM code.

When I first released the CodeWarrior projects for OpenEXR, I asked the 
list if anyone wanted Windows targets, and nobody responded, so I 
decided not to try to get that working.  But like I said, I can't see 
any reason why that shouldn't work.  Definitely feel free to post the 
results of any tests that fail here.

- Paul


On Aug 20, 2004, at 2:25 PM, Darrin Cardani wrote:

> As mentioned earlier, I'm building the OpenEXR source for Windows 
> using CodeWarrior Pro 8.3 on Mac OS X. I'm seeing 2 odd failures with 
> ImathTest. The first is pretty serious. Imath::floor<float> doesn't 
> appear to be behaving correctly. Line 97 of testFun.cpp looks like 
> this:
>
> assert (Imath::floor (-0.5f) == -1);
>
> I get an assertion there. That function looks like this:
>
> template <class T>
> inline int
> floor (T x)
> {
>     return (x >= 0)? int (x): -(int (-x) + (-x > int (-x)));
> }
>
> It turns out that the last part of that statement (-x > int (-x)) is 
> not being evaluated properly in my build. For -0.5, the result of that 
> comparison is 0 rather than 1. If I rewrite the function like this:
>
> template <class T>
> inline int
> floor (T x)
> {
>     if (x >= 0) {
>         return int (x);
>     } else {
>         int     iNegX   = int (-x);
>         T       negX    = -x;
>         int     result  = 0;
>         if (negX > iNegX) {
>                 result = 1;
>         }
>         return -(iNegX + result);
>     }
> }
>
> it returns the correct result and passes the test, though.
>
> The other problem I'm seeing is similar to Daniel Fort's problem, 
> where the Euler Angle Extraction tests are failing. However, unlike in 
> Daniel's case, I am getting seriously large error values (like 
> -0.0926975, -1.92239, etc.).
>
> I noticed that some of the #defines for Windows weren't defined in my 
> build, so I defined them by hand and rebuilt. Also, some of the STL 
> #defines weren't defined, despite the fact that I have the functions 
> in question. (Things like HAVE_IOS_BASE.) This is probably just a 
> Metrowerks issue. Defining them and rebuilding succeeded, however, it 
> didn't solve the test failures.
>
> I don't know much about how Euler angles are calculated, so I don't 
> feel confident debugging this problem myself. Would it be OK if I ran 
> the tests that Florian recommended to Daniel and post the results of a 
> few of the failures here?
>
> Thanks,
> Darrin
> --
> Darrin Cardani - address@hidden
> President, Buena Software, Inc.
> <http://www.buena.com/>
> Video, Image and Audio Processing Development
>
>
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/openexr-devel