This is related to PR 196712 and blocks updating the default version of GCC from 4.8 to 4.9. I believe what is happening here is that OpenEXR uses GCC on older versions of FreeBSD and when linking with the OpenEXR libraries we then fail to pull in the proper NEWER GCC run-time libraries. This can be fixed by building (or at least linking) with the same compiler that OpenEXR is built with. See OpenEXR/Makefile for how this is done there. http://package18.nyi.freebsd.org/data/93i386-default-PR196712/2015-01-18_16h49m19s/logs/errors/luxrender-1.3.1_4.log Linking CXX executable luxcomp /usr/local/bin/cmake -E cmake_link_script CMakeFiles/luxcomp.dir/link.txt --verbose=1 /usr/bin/c++ -O2 -pipe -fno-strict-aliasing -O2 -pipe -fno-strict-aliasing -fvisibility=hidden -fvisibility-inlines-hidden CMakeFiles/luxcomp.dir/tools/luxcomp.o -o luxcomp -L/usr/local/lib liblux.so -pthread /wrkdirs/usr/ports/graphics/luxrender/work/luxrender-luxrays-7459cd8a9583/lib/libluxrays.a /wrkdirs/usr/ports/graphics/luxrender/work/luxrender-luxrays-7459cd8a9583/lib/libsmallluxgpu.a /usr/local/lib/libGLU.so /usr/local/lib/libGL.so /usr/local/lib/libSM.so /usr/local/lib/libICE.so /usr/local/lib/libX11.so /usr/local/lib/libXext.so /usr/local/lib/libfreeimage.so /usr/local/lib/libIex.so /usr/local/lib/libIlmImf.so /usr/local/lib/libHalf.so /usr/local/lib/libImath.so /usr/local/lib/libIlmThread.so /usr/local/lib/libpng.so -lz /usr/local/lib/libboost_thread.so /usr/local/lib/libboost_program_options.so /usr/local/lib/libboost_filesystem.so /usr/local/lib/libboost_serialization.so /usr/local/lib/libboost_iostreams.so /usr/local/lib/libboost_regex.so /usr/local/lib/libboost_system.so /usr/local/lib/libfftw3.so -Wl,-rpath,"\$ORIGIN:/usr/local/lib" /usr/local/lib/libIlmImf.so: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)@GLIBCXX_3.4.20' *** [luxcomp] Error code 1
Auto-assigned to maintainer danfe@FreeBSD.org
OpenEXR no longer employes USE_GCC=yes, so this issue should be resolved without changes to graphics/luxrender. Note: this part was _broken_ even without the lang/gcc update, since someone could have lang/gcc49 or lang/gcc5 installed which would have satisfied USE_GCC=yes.