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
