openexr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Openexr-devel] OpenEXR 2.2 and OSX


From: Larry Gritz
Subject: Re: [Openexr-devel] OpenEXR 2.2 and OSX
Date: Sat, 16 Aug 2014 14:47:14 -0700

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 <address@hidden> 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 <address@hidden> 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
address@hidden




_______________________________________________
Openexr-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/openexr-devel


--
Larry Gritz
address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]