Bug 197898

Summary: graphics/hugin fails to build when USE_GCC=yes implies GCC 4.9
Product: Ports & Packages Reporter: Gerald Pfeifer <gerald>
Component: Individual Port(s)Assignee: Vasil Dimov <vd>
Status: Closed FIXED    
Severity: Affects Some People CC: mandree
Priority: --- Flags: bugzilla: maintainer-feedback? (vd)
Version: Latest   
Hardware: Any   
OS: Any   
Bug Depends on:    
Bug Blocks: 196712    

Description Gerald Pfeifer freebsd_committer 2015-02-22 01:38:40 UTC
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. 


/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
Comment 1 Bugzilla Automation freebsd_committer 2015-02-22 01:38:40 UTC
Auto-assigned to maintainer vd@FreeBSD.org
Comment 2 Vasil Dimov freebsd_committer 2015-02-23 10:34:22 UTC
Are you suggesting to put:

.if ${COMPILER_TYPE} == gcc
USE_GCC=        yes

this in graphics/hugin/Makefile ?
Comment 3 Gerald Pfeifer freebsd_committer 2015-02-26 15:14:43 UTC
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?
Comment 4 Matthias Andree freebsd_committer 2015-02-27 00:38:19 UTC
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...
Comment 5 commit-hook freebsd_committer 2015-02-27 07:40:13 UTC
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

  Try to use the same compiler as graphics/OpenEXR

  PR:		197898

Comment 6 Vasil Dimov freebsd_committer 2015-02-27 07:42:06 UTC
I have added:

.if ${COMPILER_TYPE} == gcc
USE_GCC=        yes

to graphics/hugin/Makefile in r380067.

Feel free to suggest a better fix.
Comment 7 Vasil Dimov freebsd_committer 2015-03-04 08:54:04 UTC
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.
Comment 8 Gerald Pfeifer freebsd_committer 2015-03-15 21:13:50 UTC
This looks fine.  Thank you, Vasil!