display_adaptive_tmo.cpp: At global scope: display_adaptive_tmo.cpp:308:32: error: 'constexpr' needed for in-class initialization of static data member 'const double conditional_density::l_min' of non-integral type [-fpermissive] static const double l_min = -8.f, l_max = 8.f, delta = 0.1f; ^~~ display_adaptive_tmo.cpp:308:45: error: 'constexpr' needed for in-class initialization of static data member 'const double conditional_density::l_max' of non-integral type [-fpermissive] static const double l_min = -8.f, l_max = 8.f, delta = 0.1f; ^~~ display_adaptive_tmo.cpp:308:58: error: 'constexpr' needed for in-class initialization of static data member 'const double conditional_density::delta' of non-integral type [-fpermissive] static const double l_min = -8.f, l_max = 8.f, delta = 0.1f; ^~~~ display_adaptive_tmo.cpp:375:35: error: 'constexpr' needed for in-class initialization of static data member 'const double conditional_density::l_min' of non-integral type [-fpermissive] const double conditional_density::l_min, conditional_density::l_max, conditional_density::delta; ^~~~~ display_adaptive_tmo.cpp:375:63: error: 'constexpr' needed for in-class initialization of static data member 'const double conditional_density::l_max' of non-integral type [-fpermissive] const double conditional_density::l_min, conditional_density::l_max, conditional_density::delta; ^~~~~ display_adaptive_tmo.cpp:375:91: error: 'constexpr' needed for in-class initialization of static data member 'const double conditional_density::delta' of non-integral type [-fpermissive] const double conditional_density::l_min, conditional_density::l_max, conditional_density::delta; ^~~~~ build log: http://sprunge.us/jPOX
Created attachment 182628 [details] this patch fixes build of graphics/pfstmo port by gcc6 compiler and some issues detected by portlint
Thank you, Iouri. I'll take this from here, will create a commit message, and apply.
So, working on this I noticed to things: - Lots of renaming of patch files, which we generally should not do just to appease portlint or sfor similar reasons. Is this something you can avoid or at least minimize? - Somehow this port does not appear to be able to fetch its sources any longer? Can you reproduce this? (Sorry that this took longer on my end than I had expected. Your help is much appreciated.)
A commit references this bug: Author: rakuco Date: Sat Aug 5 10:29:55 UTC 2017 New revision: 447395 URL: https://svnweb.freebsd.org/changeset/ports/447395 Log: Point MASTER_SITES to a working location. The directory where the tarball resides has changed upstream. PR: 219299 Changes: head/graphics/pfstmo/Makefile
A commit references this bug: Author: rakuco Date: Sat Aug 5 10:31:02 UTC 2017 New revision: 447396 URL: https://svnweb.freebsd.org/changeset/ports/447396 Log: MFH: r447395 Point MASTER_SITES to a working location. The directory where the tarball resides has changed upstream. PR: 219299 Approved by: ports-secteam (blanket approval) Changes: _U branches/2017Q3/ branches/2017Q3/graphics/pfstmo/Makefile
A commit references this bug: Author: rakuco Date: Sat Aug 5 10:36:05 UTC 2017 New revision: 447397 URL: https://svnweb.freebsd.org/changeset/ports/447397 Log: Explicitly build with -std=gnu++03. This was the default for GCC until version 6, which switched to -std=gnu++14. This project is unmaintained upstream and it is not worth fixing the code instead of just building with the standard it's always worked with. PR: 219299 Approved by: portmgr (blanket approval) Changes: head/graphics/pfstmo/Makefile
Given the lack of response, I've landed a much smaller fix to get the port building with GCC 6. Iouri, if you're still interested in maintaining the port please send a separate PR for that. Thanks!