Bug 197906 - graphics/vips fails to build when USE_GCC=yes implies GCC 4.9
Summary: graphics/vips fails to build when USE_GCC=yes implies GCC 4.9
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Danilo Egea Gondolfo
Depends on:
Blocks: 196712
  Show dependency treegraph
Reported: 2015-02-22 01:54 UTC by Gerald Pfeifer
Modified: 2015-04-09 23:46 UTC (History)
1 user (show)

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

patch (750 bytes, patch)
2015-02-23 23:30 UTC, Danilo Egea Gondolfo
no flags Details | Diff

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


-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 2015-02-22 01:54:20 UTC
Auto-assigned to maintainer danilo@FreeBSD.org
Comment 2 Danilo Egea Gondolfo freebsd_committer 2015-02-23 23:30:52 UTC
Created attachment 153403 [details]
Comment 3 Danilo Egea Gondolfo freebsd_committer 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 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 2015-02-26 18:43:56 UTC
Okay, I'll wait for a final decision.
Comment 6 Matthias Andree freebsd_committer 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 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).