Bug 197906

Summary: graphics/vips fails to build when USE_GCC=yes implies GCC 4.9
Product: Ports & Packages Reporter: Gerald Pfeifer <gerald>
Component: Individual Port(s)Assignee: Danilo Egea Gondolfo <danilo>
Status: Closed Overcome By Events    
Severity: Affects Some People CC: mandree
Priority: --- Flags: bugzilla: maintainer-feedback? (danilo)
Version: Latest   
Hardware: Any   
OS: Any   
Bug Depends on:    
Bug Blocks: 196712    
Attachments:
Description Flags
patch none

Description Gerald Pfeifer freebsd_committer freebsd_triage 2015-02-22 01:54:20 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/vips-7.42.1.log

-lhdf5 -lz   -L/usr/local/lib -lexif   -lm  
libtool: link: cc -std=gnu99 -O2 -pipe -fno-strict-aliasing -o .libs/introspect introspect.o -DG_DISABLE_ASSERT -DG_DISABLE_CHECKS -pthread -I/usr/local/lib/glib-2.0/include -I/usr/local/include/pango-1.0 -I/usr/local/include/orc-0.4 -I/usr/local/include/libxml2 -I/usr/local/include/libpng16 -I/usr/local/include/libgsf-1 -I/usr/local/include/harfbuzz -I/usr/local/include/glib-2.0 -I/usr/local/include/freetype2 -I/usr/local/include/OpenEXR -I/usr/local/include/GraphicsMagick -I/usr/local/include -Wl,--export-dynamic -pthread -pthread  -L/usr/local/lib -lgirepository-1.0 ./.libs/libvips.so -lGraphicsMagick -lpng16 -ltiff -ljpeg -lgmodule-2.0 -lpangoft2-1.0 -lpango-1.0 -lfontconfig -lfreetype -lgsf-1 -lgobject-2.0 -lglib-2.0 -lintl -lxml2 -lfftw3 -lorc-0.4 /usr/local/lib/liblcms2.so -lIlmImf -lImath-2_2 -lIexMath-2_2 -lHalf -lIex-2_2 -lIlmThread-2_2 -lcfitsio -lwebp -lmatio -lhdf5 -lz -lexif -lm -pthread -Wl,-rpath -Wl,/usr/local/lib
/usr/local/lib/libIlmImf.so: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)@GLIBCXX_3.4.20'
Makefile:708: recipe for target 'introspect' failed
gmake[3]: *** [introspect] Error 1
gmake[3]: Leaving directory '/wrkdirs/usr/ports/graphics/vips/work/vips-7.42.1/libvips'
Makefile:826: recipe for target 'all-recursive' failed
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory '/wrkdirs/usr/ports/graphics/vips/work/vips-7.42.1/libvips'
Makefile:626: recipe for target 'all-recursive' failed
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory '/wrkdirs/usr/ports/graphics/vips/work/vips-7.42.1'
Makefile:530: recipe for target 'all' failed
gmake: *** [all] Error 2
*** [do-build] Error code 1
Comment 1 Bugzilla Automation freebsd_committer freebsd_triage 2015-02-22 01:54:20 UTC 
Auto-assigned to maintainer danilo@FreeBSD.org
Comment 2 Danilo Egea Gondolfo freebsd_committer freebsd_triage 2015-02-23 23:30:52 UTC 
Created attachment 153403 [details]
patch
Comment 3 Danilo Egea Gondolfo freebsd_committer freebsd_triage 2015-02-23 23:32:31 UTC 
Is this patch enough to fix the problem? I've tried on fbsd 9.3 + gcc4.9 as default compiler and it works fine.
Comment 4 Gerald Pfeifer freebsd_committer freebsd_triage 2015-02-26 15:16:49 UTC 
This looks good to me, thank you.

Note the latest comments in PR 196712, specifically comment #17,
where a slightly different approach (that also requires changes
to OpenEXR) was suggested.

mandree@, what is your take?
Comment 5 Danilo Egea Gondolfo freebsd_committer freebsd_triage 2015-02-26 18:43:56 UTC 
Okay, I'll wait for a final decision.
Comment 6 Matthias Andree freebsd_committer freebsd_triage 2015-04-09 21:03:56 UTC 
Please re-check in the light of the recent OpenEXR 2.2.0_5 update.
Comment 7 Gerald Pfeifer freebsd_committer freebsd_triage 2015-04-09 23:46:51 UTC 
I believe based on OpenEXR "losing" USE_GCC=yes this can be closed
without having to patch this specific port.  Thank you so much for
looking into this so quickly Danilo (and sorry for missing to go
ahead with the patch right away back then, even if know we would
have to revert it, but that was not foreseeable).