Bug 197898 - graphics/hugin fails to build when USE_GCC=yes implies GCC 4.9
Summary: graphics/hugin fails to build when USE_GCC=yes implies GCC 4.9
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Vasil Dimov
URL:
Keywords:
Depends on:
Blocks: 196712
  Show dependency treegraph
 
Reported: 2015-02-22 01:38 UTC by Gerald Pfeifer
Modified: 2015-03-15 21:13 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (vd)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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. 


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
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
.endif

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

Log:
  Try to use the same compiler as graphics/OpenEXR

  PR:		197898

Changes:
  head/graphics/hugin/Makefile
Comment 6 Vasil Dimov freebsd_committer 2015-02-27 07:42:06 UTC
I have added:

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

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!