Re: OpenEXR 2.2 and OSX

No, that's straight from GitHub, using the v2.2.0 tag.

It seems to be all about the Homebrew version of OpenEXR 2.1 installed in /usr/local.

I was able to get it to build, but only by doing the silly movement of the old installation and then move it back after I built.

	-- lg


On Aug 16, 2014, at 10:55 AM, Piotr Stanczyk <[email protected]> wrote:

> That doesn't sound so good,  Is this coming from the tarballs or the github repo? 
> 
> Let me take a look at it on a 10.10 box
> 
> Piotr
> 
> 
> On 16 August 2014 10:41, Larry Gritz <[email protected]> wrote:
> I found compiling on OSX Mavericks to be really hard because of my Homebrew installation of 2.1 in /usr/local.  Got lots of errors like this:
> 
> ...
> libtool: link: g++ -dynamiclib  -o .libs/libIlmImfUtil-2_2.22.dylib  .libs/ImfImageChannel.o .libs/ImfFlatImageChannel.o .libs/ImfDeepImageChannel.o .libs/ImfSampleCountChannel.o .libs/ImfImageLevel.o .libs/ImfFlatImageLevel.o .libs/ImfDeepImageLevel.o .libs/ImfImage.o .libs/ImfFlatImage.o .libs/ImfDeepImage.o .libs/ImfImageIO.o .libs/ImfFlatImageIO.o .libs/ImfDeepImageIO.o .libs/ImfImageDataWindow.o   -L/Users/lg/packages/openexr.git/install/lib -L/usr/local/lib -L../IlmImf /Users/lg/packages/openexr.git/install/lib/libImath.dylib /Users/lg/packages/openexr.git/install/lib/libHalf.dylib /Users/lg/packages/openexr.git/install/lib/libIlmThread.dylib /Users/lg/packages/openexr.git/install/lib/libIex.dylib -lpthread -lIlmImf  -O2   -install_name  /Users/lg/packages/openexr.git/install/lib/libIlmImfUtil-2_2.22.dylib -compatibility_version 23 -current_version 23.0 -Wl,-single_module
> Undefined symbols for architecture x86_64:
>   "Imf_2_2::OutputFile::writePixels(int)", referenced from:
>       Imf_2_2::saveFlatScanLineImage(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, Imf_2_2::Header const&, Imf_2_2::FlatImage const&, Imf_2_2::DataWindowSource) in ImfFlatImageIO.o
>   "Imf_2_2::OutputFile::setFrameBuffer(Imf_2_2::FrameBuffer const&)", referenced from:
>       Imf_2_2::saveFlatScanLineImage(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, Imf_2_2::Header const&, Imf_2_2::FlatImage const&, Imf_2_2::DataWindowSource) in ImfFlatImageIO.o
>   "Imf_2_2::OutputFile::OutputFile(char const*, Imf_2_2::Header const&, int)", referenced from:
>       Imf_2_2::saveFlatScanLineImage(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, Imf_2_2::Header const&, Imf_2_2::FlatImage const&, Imf_2_2::DataWindowSource) in ImfFlatImageIO.o
> ... and on and on ...
> 
> 
> I just couldn't figure out how to get it to not be confused by the existing OpenEXR installation. I was eventually able to make it work only by temporarily doing:
> 
> cd /usr/local/lib
> mkdir save
> mv *Ilm* save
> 
> then building, then moving the 2.1 libraries back to their old spot.
> 
> It seems like that shouldn't be necessary. It can't be uncommon to have an older OpenEXR in the system area but be speculatively building 2.2 or a development branch somewhere else. The build system should look to the local build for libraries before any system areas without having to mess with system files, env variables, or special configure arguments.
> 
> 
> --
> Larry Gritz
> [email protected]
> 
> 
> 
> 
> _______________________________________________
> Openexr-devel mailing list
> [email protected]
> https://lists.nongnu.org/mailman/listinfo/openexr-devel
> 

--
Larry Gritz
[email protected]

_______________________________________________
Openexr-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/openexr-devel