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/hugin-2013.0.0_5.log /usr/bin/c++ -O2 -pipe -fno-strict-aliasing -O3 -O2 -pipe -fno-strict-aliasing CMakeFiles/celeste_standalone.dir/Main.cpp.o -o celeste_standalone -L/usr/local/lib libceleste.so.0.0 /usr/local/lib/libImath.so /usr/local/lib/libIlmImf.so /usr/local/lib/libIex.so /usr/local/lib/libHalf.so /usr/local/lib/libIlmThread.so /usr/local/lib/libjpeg.so /usr/local/lib/libtiff.so /usr/local/lib/libpng.so -lz -lz /usr/local/lib/libexiv2.so ../hugin_base/libhuginbase.so.0.0 /usr/local/lib/libboost_thread.so /usr/local/lib/libboost_date_time.so /usr/local/lib/libboost_regex.so /usr/local/lib/libboost_filesystem.so /usr/local/lib/libboost_iostreams.so /usr/local/lib/libboost_system.so /usr/local/lib/libboost_signals.so /usr/local/lib/libpano13.so /usr/local/lib/libGLEW.so ../foreign/levmar/libhuginlevmar.a ../foreign/vigra/vigra_impex/libhuginvigraimpex.so.0.0 -lpthread /usr/local/lib/libImath.so /usr/local/lib/libIlmImf.so /usr/local/lib/libIex.so /usr/local/lib/libHalf.so /usr/local/lib/libIlmThread.so /usr/local/lib/libjpeg.so /usr/local/lib/libpng.so -lz /usr/local/lib/libtiff.so /usr/local/lib/libexiv2.so -pthread ../hugin_base/makefilelib/libmakefilelib.so.0.0 /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/libglut.so /usr/local/lib/libXmu.so /usr/local/lib/libXi.so /usr/local/lib/liblensfun.so /usr/local/lib/libboost_thread.so /usr/local/lib/libboost_date_time.so /usr/local/lib/libboost_regex.so /usr/local/lib/libboost_filesystem.so /usr/local/lib/libboost_iostreams.so /usr/local/lib/libboost_system.so /usr/local/lib/libboost_signals.so /usr/local/lib/libpano13.so /usr/local/lib/libGLEW.so -Wl,-rpath,/usr/local/lib:/wrkdirs/usr/ports/graphics/hugin/work/hugin-2013.0.0/src/celeste:/wrkdirs/usr/ports/graphics/hugin/work/hugin-2013.0.0/src/hugin_base:/wrkdirs/usr/ports/graphics/hugin/work/hugin-2013.0.0/src/foreign/vigra/vigra_impex:/wrkdirs/usr/ports/graphics/hugin/work/hugin-2013.0.0/src/hugin_base/makefilelib: /usr/local/lib/libIlmImf.so: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)@GLIBCXX_3.4.20' *** [src/celeste/celeste_standalone] Error code 1
Auto-assigned to maintainer vd@FreeBSD.org
Are you suggesting to put: .if ${COMPILER_TYPE} == gcc USE_GCC= yes .endif this in graphics/hugin/Makefile ?
Yes, this should address the issue. Perhaps also check out PR 196712, specifically comment #17, where a slightly different approach (that also requires changes to OpenEXR). mandree@, what is your take?
Anything that avoids the decrepit base r4.2 gcc and uses the default C++ standard library of the default compiler should do. If passing c++11-lang to USES=compiler, meaning that it uses a newer gcc 4.x on 8/9, and clang on 10+ systems where we have clang support for the architecture, it should work. If we mix different compiler versions (for the run-time support libraries) or ABIs (libc++ vs. libstdc++), then a slave port will fail no matter how we word the requisites. The only way out would be to link the rt support statically, but I'm not sure if that's supported or causes run-time issues as objects are passed around by the application...
A commit references this bug: Author: vd Date: Fri Feb 27 07:39:44 UTC 2015 New revision: 380067 URL: https://svnweb.freebsd.org/changeset/ports/380067 Log: Try to use the same compiler as graphics/OpenEXR PR: 197898 Changes: head/graphics/hugin/Makefile
I have added: .if ${COMPILER_TYPE} == gcc USE_GCC= yes .endif to graphics/hugin/Makefile in r380067. Feel free to suggest a better fix.
I am closing this as the mentioned fix has been committed. Feel free to reopen it if you feel that a different approach should be used.
This looks fine. Thank you, Vasil!