Re: [Openexr-devel] Trying to compile 1.1.0 with 2.95.3 compiler, unsuccessfully

[Drew Hess]

Hey Thad,

Yeah, this is a known problem with gcc 2.95 and OpenEXR 1.1.x.  We'll try
to get it fixed in time for the 1.2 release.  It may turn out, though,
that Shake on GNU/Linux will only work with 1.0.7 until Apple starts using
gcc 3.x.

In the meantime, as a workaround, you can run exrmaketiled on the scanline 
files that the Shake plugin is outputting.

By the way, you should be using OpenEXR 1.1.1, since the 1.1.0 version 
produces tiled files which are broken and no longer supported.  If you 
have tiled files that you generated using 1.1.0, there is a way to convert 
them to the new format, so let me know if that's an issue for you.


-dwh-


On Sun, 4 Apr 2004, Thad Beier wrote:

> In the wonderful world of C++ (pronounced, of course, C-double-cross) 
> you have
> to always be extremely careful about which version of the compiler you 
> are using,
> as they have different ways of mangling programs.  Or something.  I 
> don't know how
> people do it.
> 
> Anyway.
> 
> I was attempting to compile the OpenEXR Shake plugin, and have 
> successfully compiled
> the 1.0.7 version with the 2.95.3 version of g++ (by creating a image of 
> my development
> environment, installing 2.95.3, and chroot-ing to that environment.  How 
> do other people
> do it?)
> 
> This works, and the plugin works.
> 
> But, if I wanted to read and write modern, tiled OpenEXR files, I'd have 
> to have the 1.1.0
> version of the library.  When I try to compile it with the 2.95.3 
> compiler, I get a rather
> voluminous set of error messages, apparently starting with
> 
>     
> /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_algobase.h:
>  
> In function `static Int64 * __c
>     opy_dispatch<const long long unsigned int *,long long unsigned int 
> *,__true_type>::copy(const Int64 *, const Int64 *, Int
>     64 *)':
>     
> /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_algobase.h:177:
>  
> template instantiation dept
>     h exceeds maximum of 17
>     
> /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_algobase.h:177:
>   
> (use -ftemplate-depth-NN t
>     o increase the maximum)
>     
> /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_algobase.h:177:
>    
> instantiating `__copy_tri
>     vial<Int64>(const Int64 *, const Int64 *, Int64 *)'
>     
> /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_algobase.h:177:
>    
> instantiated from `__copy
>     _dispatch<const long long unsigned int *,long long unsigned int 
> *,__true_type>::copy(const Int64 *, const Int64 *, Int64
>     *)'
>     
> /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_algobase.h:188:
>    
> instantiated from `copy<c
>     onst Int64 *, Int64 *>(const Int64 *, const Int64 *, Int64 *)'
> 
> 
> 
> 
> I'm assuming that all the messages about
> 
>     ImfTiledInputFile.cpp: In method `void 
> Imf::TiledInputFile::readTile(int, int, int, int)':
>     ImfTiledInputFile.cpp:640: warning: choosing 
> `Imf::Array<char>::operator char *()' over `Imf::Array<char>::operator const
>  char *() const'
> 
> are an inside joke that I'm just late to be clued in about.
> 
> Don't get me wrong -- I love OpenEXR, I love the PIZ wavelet 
> compression, I love HDR.  I just hate C++.
> 
> Thad Beier
> Hammerhead Productions
> 
> 
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/openexr-devel
> 
>