Created attachment 155833 [details] Upgrade Boost to 1.58 Upgrade Boost to 1.58. The enclosed patch file upgrades following ports: devel/boost-all devel/boost-docs devel/boost-jam devel/boost-libs devel/boost-python-libs There is also a pull request on Github with same changes: https://github.com/freebsd/freebsd-ports/pull/28 Regards, Chen
This unfortunately has too many fallout as boost for unknown reason do not expose anymore BOOST_NO_LONG_LONG things like libe-book are now failing to build
Created attachment 155835 [details] Complete patch which allows building with gcc 4.2.1 This patch allows to reuse properly the regular build framework from Mk/* Accept gcc 4.2.1 as a compiler but still have many fallouts
*** Bug 192537 has been marked as a duplicate of this bug. ***
*** Bug 198751 has been marked as a duplicate of this bug. ***
Just checked the long discussion under 192537, seems a lot of trouble. Just for my curiosity, what is the standard procedure for such situation? Should we just keep Boost out-of-date or try to upgrade dependents?
Hi, boost mpi shared library seems missing `bjam --with-mpi` option. Maybe a new port very similar to boost-python-libs could be added (e.g "boost-mpi-libs")? Regards G. Dollé
(In reply to Chen Xu from comment #5) In this case there is something we are missing somewhere :) probably a typo or something obvious that is messing with BOOST_NO_LONG_LONG so the procedure is to find out what is the reason for that and fix it, then it should fix most of the dependency problem
Hi folks, just wondering if there had been any further progress on this, and if there was anything concrete I could do to assist? Note that in the interim Boost 1.59 is now out. Regards, Roger
Nope, no progress here, and if one is interested to help he should try to figured the BOOST_NO_LONG_LONG issue I explained in an earlier comment
I'd like to contribute to this dialog that, yes, stuff would break - but also without having a newer boost it's also getting harder to install software that needs it. For example the new DHCPv4/DHCPv6 server developed by ISC.
You just miss the point that it is not things that would break but the entirely FreeBSD9 that would break or FreeBSD on platforms not supported by clang, this is a real bug in boost vs gcc 4.2 that needs to be figured out. Having a few things that breaks we can handle that.
Hi, guys, As I can see there are a lot of troubles to upgrade boost, now I'm thinking about another approach. How about to rename original boost port to something like boost-147, change all dependencies accordingly, then we can add a new port for new boost. Also we can mark new boost port as it only compatible with recent versions of Clang of GCC, and/or FreeBSD. Regards, Chen
In the case of libe-book, the problem isn't caused a change in BOOST_NO_LONG_LONG vs. BOOST_HAS_LONG_LONG between 1.55 and 1.58. Both of these versions of boost always define BOOST_HAS_LONG_LONG whenever they are built with either gcc or clang. The libe-book build failure is triggered by the 1.58 version of boost::unordered, which tries to use "long long" if BOOST_HAS_LONG_LONG is defined, which causes a compilation error because the libe-book build passes the -pedantic flag to gcc. Unfortunately there does not seem to be a way of detecting the use of -pedantic when compiling with gcc. The __LONG_LONG_SUPPORTED logic in <sys/cdefs.h> attempts to handle this by checking __STRICT_ANSI__, but that is controlled by the -ansi compiler flag, not the -pedantic flag. Adding a check for __STRICT_ANSI__ to boost would not fix libe-book because it does not specify the -ansi flag. It is possible to fix the libe-book build by patching boost to only enable BOOST_HAS_LONG_LONG when compiling with -std=c++11 (or c99), but this breaks boost on i386 because it is unable to figure out how to handle 64-bit integral types without BOOST_HAS_LONG_LONG. That can also be fixed, and I was able to build libe-book on FreeBSD 9.3 and 10.1 on both amd64 and i386. My concern is that there could be considerable fallout by ripping boost "long long" support from under ports that expect it but are not using the appropriate -std setting, and were not previously experiencing build failures because they were not building with -pedantic.
maybe it is worth trying to disable BOOST_HAS_LONG_LONG the way you propose and see what an exp-run says about the fallouts.
Deviating so significantly from upstream behavior bothers me, which got me wondering how libe-book manages to build on linux. Surely if it didn't build on linux, then it would get fixed. As an experiment, I tried compiling some code using "long long" with g++48 -pedantic. The compiler warns about "long long", but it is not a fatal error. Based on that, I think I'll try limiting the hack to only when we are using our ancient version of gcc. With clang it is also a non-fatal warning. For ports that prove troublesome, the best thing to do might be to tell them to use a better compiler. I'm currently working on a baseline for a local mini exp-run. I've got 304 ports on my list of boost consumers, which requires building somewhat more than 1000 ports total. I think I can build the full set in about 12 hours per arch/os combo on my available hardware. Testing the new boost version should take somehat less than that. While the baseline is getting built, I'll start looking at 1.59. If we're going to go through all this trouble ... Once I get something that looks promising, then we can do a real exp-run.
As an experiment, I tried a test compile with "-isystem /usr/local/include" instead of "-I/usr/local/include" and that got rid of the compiler errors, so USES+=localbase might be a viable way to fix individual ports affected by BOOST_*_LONG_LONG.
I have some preliminary results for building on FreeBSD 9.3 i386 with ports version r399104. It looks like patching the port to assert BOOST_NO_LONG_LONG is the wrong path to take because the fallout is much worse with this patch even though it fixes libe-book. Baseline with boost 1.55: Built: 1004 Failed: 4 Skipped: 17 Ignored: 18 Stock boost 1.58: Built: 273 Failed: 35 Skipped: 22 Ignored: 17 Boost 1.58 with BOOST_NO_LONG_LONG hack: Built: 229 Failed: 68 Skipped: 34 Ignored: 16 Boost 1.59: Built: 242 Failed: 48 Skipped: 40 Ignored: 17 It's disappointing that 1.59 is so much worse than 1.58. It makes the decision on whether or not to jump all the way to 1.59 more difficult. A significant number of the skipped ports are due to a build failure in math/py-numpy, which is not boost related and happens even in the baseline. I don't know why this port is failing for me because the portsmon build is clean. Baseline failures: databases/mariadb-server:build databases/mariadb55-server:package math/py-numpy:build sysutils/osquery:build Additional build failures with 1.58: audio/clementine-player:build cad/openscad:build databases/sfcgal:build deskutils/kdepim4:build devel/kdevplatform:build devel/liblas:build devel/liborcus:build devel/luabind:build finance/ledger:build games/allacrost:build games/plee-the-bear:build games/valyriatear:build graphics/appleseed:build graphics/aqsis:build graphics/evolvotron:build graphics/hugin:build graphics/mapnik:build graphics/mitsuba:build graphics/scantailor:build math/pdal:build multimedia/aegisub:build multimedia/gstreamer-qt4:build multimedia/gstreamer1-qt4:build net-p2p/dogecoin:build net-p2p/namecoin:build net-p2p/zetacoin:build security/quantis:build textproc/libe-book00:build textproc/libe-book:build textproc/luceneplusplus:build x11/leechcraft:build Additional build failures with BOOST_NO_LONG_LONG hack (vs stock 1.58): audio/ardour:build audio/mp3plot:configure converters/osm2pgsql:build databases/hamsterdb:configure devel/avro-cpp:build devel/cpp-netlib:build devel/eblob:build devel/libiqxmlrpc:build devel/liborcus07:build devel/ros:build devel/smack:build devel/synfig:configure editors/openoffice-4:build games/alephone:build games/frogatto:build games/glob2:build games/pokerth:build games/wesnoth:build graphics/fracplanet:build graphics/gnash:build graphics/openimageio:build graphics/povray37:configure math/cgal:build math/rocs:build math/stp:build multimedia/cclive:build multimedia/plexhometheater:build net-mgmt/fastnetmon:build net-mgmt/icinga2:build net-p2p/digitalcoin:build net-p2p/litecoin:configure net-p2p/qbittorrent:build net-p2p/twister:build net-p2p/zetacoin:configure net/pktanon:configure science/bddsolve:build science/pulseview:build textproc/kenlm:build textproc/libkolabxml:build textproc/xmlwrapp:configure Fixed by BOOST_NO_LONG_LONG hack: textproc/libe-book00:build textproc/libe-book:build and net-p2p/zetacoin went from a configure failure to a build failure. Additional build failures with 1.59 (vs stock 1.58): deskutils/pinot:build devel/avro-cpp:build devel/boost-python-libs:checksum devel/codeblocks:build graphics/gnash:build graphics/libcdr01:build graphics/libetonyek01:build graphics/libfreehand:build print/libmspub01:build print/libpagemaker:build textproc/libabw:build textproc/libmwaw03:build textproc/libvisio01:build textproc/libvisio:build textproc/libwpd010:build textproc/libwps03:build textproc/libwps:build www/anyterm:build I've started a test of FreeBSD 10.1 amd64 to try to get some more coverage. I'll skip the BOOST_NO_LONG_LONG change this time since that appears to be a dead end. I should have the results in a day or so.
(In reply to Don Lewis from comment #17) > A significant number of the skipped ports are due to a build failure in > math/py-numpy, which is not boost related and happens even in the baseline. I > don't know why this port is failing for me because the portsmon build is clean. I had a similar problem and now it's fixed. If you're running head, you may try to update world and rebuild lang/python27 (or your default python). Basically, we briefly had some issues on head after Clang & libc++ import. FYI...
(In reply to Jung-uk Kim from comment #18) I guess I spoke too soon. Numpy just crashed at run-time. Sorry for the noise.
(In reply to Jung-uk Kim from comment #18) My package builder is running head, but the build was done in a FreeBSD 9.3 i386 poudriere jail. I'm not seeing the problem in a FreeBSD 10.1 amd64 jail. FWIW, this is what is broken: cc: build/src.freebsd-9.3-RELEASE-p24-i386-2.7/numpy/core/src/npymath/npy_math_complex.c numpy/core/src/npymath/npy_math_complex.c.src: In function 'npy_ccoshf': numpy/core/src/npymath/npy_math_complex.c.src:643: error: incompatible types in assignment numpy/core/src/npymath/npy_math_complex.c.src: In function 'npy_csinhf': numpy/core/src/npymath/npy_math_complex.c.src:785: error: incompatible types in assignment numpy/core/src/npymath/npy_math_complex.c.src: In function 'npy_ccosh': numpy/core/src/npymath/npy_math_complex.c.src:643: error: incompatible types in assignment numpy/core/src/npymath/npy_math_complex.c.src: In function 'npy_csinh': numpy/core/src/npymath/npy_math_complex.c.src:785: error: incompatible types in assignment numpy/core/src/npymath/npy_math_complex.c.src: In function 'npy_ccoshf': numpy/core/src/npymath/npy_math_complex.c.src:643: error: incompatible types in assignment numpy/core/src/npymath/npy_math_complex.c.src: In function 'npy_csinhf': numpy/core/src/npymath/npy_math_complex.c.src:785: error: incompatible types in assignment numpy/core/src/npymath/npy_math_complex.c.src: In function 'npy_ccosh': numpy/core/src/npymath/npy_math_complex.c.src:643: error: incompatible types in assignment numpy/core/src/npymath/npy_math_complex.c.src: In function 'npy_csinh': numpy/core/src/npymath/npy_math_complex.c.src:785: error: incompatible types in assignment error: Command "cc -DNDEBUG -O2 -pipe -fno-strict-aliasing -fPIC -Inumpy/core/include -Ibuild/src.freebsd-9.3-RELEASE-p24-i386-2.7/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -I/usr/local/include/python2.7 -Ibuild/src.freebsd-9.3-RELEASE-p24-i386-2.7/numpy/core/src/private -Ibuild/src.freebsd-9.3-RELEASE-p24-i386-2.7/numpy/core/src/private -Ibuild/src.freebsd-9.3-RELEASE-p24-i386-2.7/numpy/core/src/private -c build/src.freebsd-9.3-RELEASE-p24-i386-2.7/numpy/core/src/npymath/npy_math_complex.c -o build/temp.freebsd-9.3-RELEASE-p24-i386-2.7/build/src.freebsd-9.3-RELEASE-p24-i386-2.7/numpy/core/src/npymath/npy_math_complex.o" failed with exit status 1
The devel/boost-python-libs:checksum failure in the FreeBSD 9.3 boost 1.59 run was caused by my failure to update distinfo. FreeBSD 10.1 amd64 results ... Baseline with boost 1.55: Built: 912 Failed: 3 Skipped: 4 Ignored: 10 Stock boost 1.58: Built: 295 Failed: 30 Skipped: 7 Ignored: 10 Stock boost 1.59: Built: 276 Failed: 44 Skipped: 12 Ignored: 10 Baseline failures: databases/mariadb55-server:package databases/mariadb100-server:build databases/mariadb-server:build Additional failures with 1.58: audio/clementine-player:build cad/kicad:build cad/openscad:build databases/sfcgal:build deskutils/kdepim4:build devel/kdevplatform:build devel/luabind:build editors/libreoffice4:build finance/ledger:build games/allacrost:build games/valyriatear:build graphics/appleseed:build graphics/aqsis:build graphics/evolvotron:build graphics/hugin:build graphics/mapnik:build graphics/mitsuba:build graphics/scantailor:build math/pdal:build multimedia/gstreamer-qt4:build multimedia/gstreamer1-qt4:build net-p2p/dogecoin:build net-p2p/namecoin:build net-p2p/zetacoin:build security/quantis:build textproc/luceneplusplus:build x11/leechcraft:build Additional failures with 1.59 (vs 1.58): deskutils/pinot:build devel/avro-cpp:build devel/codeblocks:build graphics/libcdr01:build graphics/libetonyek01:build graphics/libfreehand:build print/libmspub01:build print/libpagemaker:build textproc/libabw:build textproc/libe-book00:build textproc/libe-book:build textproc/libmwaw03:build textproc/libvisio01:build textproc/libvisio:build textproc/libwpd010:build textproc/libwps03:build textproc/libwps:build www/anyterm:build
Created attachment 162139 [details] updated patch to upgrade to boost 1.58 This is an updated patch to catch up with changes that have been committed to the existing boost ports since the last patch was generated.
Created attachment 162140 [details] patch to upgrade to boost 1.59 (and also add long double support for recent FreeBSD) This patch upgrades boost to 1.59. It also adds long double support for FreeBSD >= 10.2 and recent FreeBSD 11.0-CURRENT.
*** Bug 204606 has been marked as a duplicate of this bug. ***
I re-ran port builds with boost 1.55 and 1.59 on FreeBSD 10.1 amd64 with ports tree r402262. This time I looked for boost in BUILD_DEPENDS and LIB_DEPENDS instead of just grepping the Makefiles for the presence of boost, which resulting in some extra ports being built this time around. I also set some non-default options in make.conf to enable the use of boost by more ports: OPTIONS_SET=REGEX OQGRAPH BOOST MOD_BOOLEAN ASIO MNUMPY DISABLE_VULNERABILITIES=yes Without these options, I found 290 ports that depend on boost. With these options, this increases to 297 ports. The summary results: boost 1.55: Built: 1062 Failed: 4 Skipped: 3 Ignored: 13 boost 1.59: Built: 276 Failed: 44 Skipped: 12 Ignored: 12 The larger number of built ports for 1.55 are mostly dependencies that were common to both builds and did not need to be rebuilt when boost was upgraded to 1.59. With boost 1.55, these are the four failing ports: databases/mariadb100-server:build databases/mariadb55-server:package graphics/hugin:configure lang/sdcc-devel:fetch When I used the patch attached to this PR to upgrade boost to 1.59, these are the additional ports that failed; audio/clementine-player:build cad/kicad:build cad/openscad:build deskutils/kdepim4:build deskutils/pinot:build devel/avro-cpp:build devel/codeblocks:build devel/kdevplatform:build devel/luabind:build editors/openoffice-devel:build finance/ledger:build games/allacrost:build games/valyriatear:build graphics/aqsis:build graphics/evolvotron:build graphics/libcdr01:build graphics/libetonyek01:build graphics/libfreehand:build graphics/mapnik:build graphics/mitsuba:build graphics/scantailor:build math/pdal:build multimedia/gstreamer-qt4:build multimedia/gstreamer1-qt4:build net-p2p/namecoin:build print/libmspub01:build print/libpagemaker:build security/quantis:build textproc/libabw:build textproc/libe-book00:build textproc/libe-book:build textproc/libmwaw03:build textproc/libvisio01:build textproc/libvisio:build textproc/libwpd010:build textproc/libwps03:build textproc/libwps:build textproc/luceneplusplus:build www/anyterm:build x11/leechcraft:build I have uploaded the build logs for the failing ports to <https://people.freebsd.org/~truckman/boost-1.59_fallout/r402262/FreeBSD-10.1-amd64/>
Arm64 support was added to boost 1.58, we'll need dither this update, or for someone to backport the build changes to get boost on arm64.
Created attachment 165420 [details] patch to upgrade to boost 1.60 (and also add long double support for recent FreeBSD) I tested this patch to upgrade boost to 1.60 on FreeBSD 10.1 amd64 with ports tree r405759 for ports that reference boost in BUILD_DEPENDS and LIB_DEPENDS, with these make.conf settings: OPTIONS_SET=REGEX OQGRAPH BOOST MOD_BOOLEAN ASIO MNUMPY DISABLE_VULNERABILITIES=yes As in my previous test for boost 1.59, I found 297 ports that reference boost. Summary results: boost 1.55: Failed: 4 Skipped: 4 Ignored: 13 boost 1.60: Failed: 42 Skipped: 13 Ignored: 12 This is actually somewhat better that my earlier results with 1.59. With boost 1.55, these are the four failing ports: databases/mariadb100-server:build databases/mariadb55-server:package games/supertux2:build lang/sdcc-devel:build With this patch to upgrade to boost 1.60, these are the additional failures: audio/clementine-player:build audio/csound6:build cad/openscad:build databases/sfcgal:build deskutils/kdepim4:build deskutils/pinot:build devel/avro-cpp:build devel/codeblocks:build devel/kdevplatform:build devel/luabind:build devel/msp430-debug-stack:build editors/openoffice-devel:build finance/ledger:build games/allacrost:build games/plee-the-bear:build games/pokerth:build games/traingame:build games/valyriatear:build graphics/aqsis:build graphics/evolvotron:build graphics/mapnik:build graphics/mitsuba:build graphics/py-openimageio:build graphics/scantailor:build lang/sdcc:build math/pdal:build multimedia/gstreamer-qt4:build multimedia/gstreamer1-qt4:build net-p2p/namecoin:build science/avogadro:build security/quantis:build textproc/libabw:build textproc/libe-book00:build textproc/libe-book:build textproc/libvisio:build textproc/luceneplusplus:build www/anyterm:build x11/leechcraft:build I have updated the build logs for the failing ports to <https://people.freebsd.org/~truckman/boost-1.60_fallout/r405759/FreeBSD-10.1-amd64/>
Created attachment 165706 [details] Patch for www/anyterm to work with boost 1.60 The attached patch fixes anyterm. As well I started a wiki page for this upgrade process: https://wiki.freebsd.org/BoostPortingProject/1.55-to-1.60
A commit references this bug: Author: amdmi3 Date: Sun Feb 7 14:58:47 UTC 2016 New revision: 408415 URL: https://svnweb.freebsd.org/changeset/ports/408415 Log: - Fix build with boost-1.60 PR: 199601 Changes: head/devel/codeblocks/Makefile
A commit references this bug: Author: amdmi3 Date: Sun Feb 7 15:25:04 UTC 2016 New revision: 408416 URL: https://svnweb.freebsd.org/changeset/ports/408416 Log: - Fix build with boost 1.60 PR: 199601 Submitted by: sperber Approved by: portmgr blanket Changes: head/www/anyterm/Makefile head/www/anyterm/files/patch-common.mk
A commit references this bug: Author: amdmi3 Date: Sun Feb 7 15:56:25 UTC 2016 New revision: 408419 URL: https://svnweb.freebsd.org/changeset/ports/408419 Log: - Fix LICENSE - Fix build with boost 1.60 - Switch to options helpers - Cosmetic fixes PR: 199601 Changes: head/graphics/evolvotron/Makefile head/graphics/evolvotron/files/patch-libfunction_useful.h
A commit references this bug: Author: amdmi3 Date: Mon Feb 8 11:16:26 UTC 2016 New revision: 408472 URL: https://svnweb.freebsd.org/changeset/ports/408472 Log: - Fix build with boost 1.60 - Fix LICENSE - Pet portlint PR: 199601 Approved by: portmgr blanket Changes: head/audio/clementine-player/Makefile head/audio/clementine-player/files/patch-src_core_mergedproxymodel.h head/audio/clementine-player/files/patch-src_library_groupbydialog.h
A commit references this bug: Author: amdmi3 Date: Mon Feb 8 11:16:36 UTC 2016 New revision: 408473 URL: https://svnweb.freebsd.org/changeset/ports/408473 Log: - Fix build with boost 1.60 - Fix LICENSE PR: 199601 Approved by: portmgr blanket Changes: head/cad/openscad/Makefile head/cad/openscad/files/ head/cad/openscad/files/patch-src_colormap.h head/cad/openscad/files/patch-src_scintillaeditor.h
A commit references this bug: Author: amdmi3 Date: Mon Feb 8 11:18:02 UTC 2016 New revision: 408474 URL: https://svnweb.freebsd.org/changeset/ports/408474 Log: - Fix build with boost 1.60 - Add LICENSE_FILE PR: 199601 Approved by: portmgr blanket Changes: head/net-p2p/namecoin/Makefile head/net-p2p/namecoin/files/patch-src_allocators.h head/net-p2p/namecoin/files/patch-src_qt_guiutil.h head/net-p2p/namecoin/files/patch-src_util.h
A commit references this bug: Author: amdmi3 Date: Mon Feb 8 11:18:44 UTC 2016 New revision: 408475 URL: https://svnweb.freebsd.org/changeset/ports/408475 Log: - Fix build with boost 1.60 PR: 199601 Changes: head/graphics/aqsis/files/patch-include_aqsis_tex_buffers_channellist.h head/graphics/aqsis/files/patch-include_aqsis_tex_buffers_mixedimagebuffer.h head/graphics/aqsis/files/patch-include_aqsis_util_socket.h head/graphics/aqsis/files/patch-tools_displays_piqsl_piqsldisplay.cpp head/graphics/aqsis/files/patch-tools_piqsl_displayserverimage.cpp head/graphics/aqsis/files/patch-tools_piqsl_image.h head/graphics/aqsis/files/patch-tools_piqsl_imagelistmodel.cpp
A commit references this bug: Author: amdmi3 Date: Mon Feb 8 11:18:49 UTC 2016 New revision: 408476 URL: https://svnweb.freebsd.org/changeset/ports/408476 Log: - Fix build with boost 1.60 PR: 199601 Approved by: portmgr blanket Changes: head/devel/avro-cpp/Makefile
A commit references this bug: Author: amdmi3 Date: Mon Feb 8 18:52:15 UTC 2016 New revision: 408498 URL: https://svnweb.freebsd.org/changeset/ports/408498 Log: - Fix build with boost 1.60 - Mark sdcc-devel MAKE_JOBS_UNSAFE as it fails with parallel build PR: 199601 Approved by: portmgr blanket Changes: head/lang/sdcc/files/patch-src_SDCClospre.hpp head/lang/sdcc/files/patch-src_SDCCnaddr.hpp head/lang/sdcc/files/patch-src_SDCCralloc.hpp head/lang/sdcc-devel/Makefile head/lang/sdcc-devel/files/patch-src_SDCClospre.hpp head/lang/sdcc-devel/files/patch-src_SDCCnaddr.hpp head/lang/sdcc-devel/files/patch-src_SDCCralloc.hpp
A commit references this bug: Author: amdmi3 Date: Mon Feb 8 19:16:00 UTC 2016 New revision: 408502 URL: https://svnweb.freebsd.org/changeset/ports/408502 Log: - Fix build with boost 1.60 - Switch to options helpers - Add LICENSE_FILE PR: 199601 Changes: head/science/avogadro/Makefile head/science/avogadro/files/patch-libavogadro_src_pythonengine__p.h head/science/avogadro/files/patch-libavogadro_src_pythonextension__p.h head/science/avogadro/files/patch-libavogadro_src_pythoninterpreter.h head/science/avogadro/files/patch-libavogadro_src_pythonscript.h head/science/avogadro/files/patch-libavogadro_src_pythontool__p.h
A commit references this bug: Author: amdmi3 Date: Tue Feb 9 10:38:39 UTC 2016 New revision: 408549 URL: https://svnweb.freebsd.org/changeset/ports/408549 Log: - Fix build of cgal consumers (sfcgal) with boost 1.60 PR: 199601 Approved by: portmgr blanket Changes: head/math/cgal/Makefile head/math/cgal/files/patch-include_CGAL_Straight__skeleton_2_Straight_skeleton_builder_2_impl.h
A commit references this bug: Author: amdmi3 Date: Tue Feb 9 11:03:06 UTC 2016 New revision: 408552 URL: https://svnweb.freebsd.org/changeset/ports/408552 Log: - Fix build with boost 1.60 PR: 199601 Approved by: portmgr blanket Changes: head/devel/msp430-debug-stack/Makefile
A commit references this bug: Author: amdmi3 Date: Tue Feb 9 14:59:56 UTC 2016 New revision: 408572 URL: https://svnweb.freebsd.org/changeset/ports/408572 Log: - Fix build with boost 1.60 PR: 199601 Approved by: portmgr blanket Changes: head/textproc/luceneplusplus/files/patch-include_VariantUtils.h
A commit references this bug: Author: amdmi3 Date: Tue Feb 9 20:21:57 UTC 2016 New revision: 408592 URL: https://svnweb.freebsd.org/changeset/ports/408592 Log: - Fix build with boost 1.60 PR: 199601 Approved by: portmgr blanket Changes: head/graphics/scantailor/Makefile head/graphics/scantailor/files/patch-MainWindow.cpp head/graphics/scantailor/files/patch-ThumbnailSequence.cpp
A commit references this bug: Author: truckman Date: Wed Feb 10 00:47:21 UTC 2016 New revision: 408611 URL: https://svnweb.freebsd.org/changeset/ports/408611 Log: Disable PDF import plugin to unbreak build with modern boost. A proper fix that can be upstreamed will take a bit longer. PR: 199601 Changes: head/editors/openoffice-devel/Makefile
While bug #173585 was closed of old age, it still would be nice to be able to get libboost_python3 installed. The new update to graphics/openimageio has support for python3 but I can't provide support for it on freebsd without libboost_python3 being installed. By duplicating the new devel/boost-python-libs and changing to USE=python:3.5 and adjusting the pkg-plist to have libboost_python3.so I can get libboost_python3 to build and package. I haven't looked into how flexible the boost-python lib is. It would appear to only install one lib on the system (/usr/local/lib not into pythonx.x/site-packages) so I don't know if it will be usable for more than one python version.
Created attachment 166861 [details] updated patch to upgrade to boost 1.60 (and also add long double support for recent FreeBSD) Fix boost-docs pkg-plist. Strip lib/libboost_python.so.
Sorry that previous bug was meant to be Bug #173575
A commit references this bug: Author: truckman Date: Thu Feb 11 15:40:54 UTC 2016 New revision: 408688 URL: https://svnweb.freebsd.org/changeset/ports/408688 Log: Unbreak PDF Import extension when building with modern boost. Similar to the patch by amdmi3, link the extension with -lboost_system, but only do this in the --with-system-boost case. Doing this unconditionally would break building with the bundled boost because only the boost headers are available and the boost libraries are not built. This is still a bit pessimal because -lboost_system may be used when it is not strictly necessary (when the system boost is old), but it is likely that this is only relevant to FreeBSD and we are in the process of upgrading boost. This fix should be acceptable upstream. Re-enable the PDF Import extension by default. When the PDF Import extension is enabled, promote boost from BUILD_DEPENDS to LIB_DEPENDS. Tested with PDFIMPORT both on and off. Also tested with PDFIMPORT on, --with-system-boost disabled, and boost removed from *_DEPENDS. PR: 207073, 199601 Changes: head/editors/openoffice-devel/Makefile head/editors/openoffice-devel/files/patch-sdext_source_pdfimport_makefile.mk
A commit references this bug: Author: amdmi3 Date: Sat Feb 13 01:26:10 UTC 2016 New revision: 408773 URL: https://svnweb.freebsd.org/changeset/ports/408773 Log: - Fix build with boost 1.60 PR: 199601 Changes: head/multimedia/gstreamer-qt4/files/ head/multimedia/gstreamer-qt4/files/patch-src_QGlib_connect.cpp head/multimedia/gstreamer-qt4/files/patch-src_QGlib_connect.h head/multimedia/gstreamer-qt4/files/patch-src_QGlib_connectimpl.h head/multimedia/gstreamer-qt4/files/patch-src_QGlib_refpointer.h head/multimedia/gstreamer-qt4/files/patch-src_QGlib_type.h head/multimedia/gstreamer-qt4/files/patch-src_QGlib_value.h
Created attachment 167007 [details] devel/qt4-moc patch with additional Boost include guards I'd appreciate it if kde@ is added to the loop when a Boost upgrade causes problems with moc-qt4 so we can try to fix it in moc itself instead of patching many files in several ports. For one, I've updated the moc section in https://wiki.freebsd.org/BoostPortingProject/1.55-to-1.60 with an explanation of why moc breaks and another approach to solving these issues. I also added some context to the existing qt4-moc patch in ports r408911. This attachment contains a patch to devel/qt4-moc that defines more include guards so that the Boost 1.60 headers that include the headers moc can't parse (basically, any header that uses macros in a namespace declaration) are skipped. I was able to build all ports in https://wiki.freebsd.org/BoostPortingProject/1.55-to-1.60 that were failing because of moc without having to patch any of them at all (basically reverting most of ports r408472, ports r408473, ports r408474, ports r408475, ports r408502, ports r408773, ports r408419, but also including all ports with a column saying "fixed by qt4-moc patch"). If there's no objection, I'd like to commit it to qt4-moc and remove all patches added in the revisions above that wrap Boost includes within #ifndef Q_MOC_RUN blocks.
(In reply to Raphael Kubo da Costa from comment #49) > If there's no objection, I'd like to commit it to qt4-moc and remove all > patches added in the revisions above that wrap Boost includes within #ifndef > Q_MOC_RUN blocks. I'm ok with that, however it'll require an exp-run.
A commit references this bug: Author: amdmi3 Date: Tue Feb 16 13:46:46 UTC 2016 New revision: 408995 URL: https://svnweb.freebsd.org/changeset/ports/408995 Log: - Fix build with clang 1.60 PR: 199601 Approved by: portmgr blanket Changes: head/graphics/mitsuba/files/patch-src_bsdfs_irawan.h
(In reply to Dmitry Marakasov from comment #50) > (In reply to Raphael Kubo da Costa from comment #49) > > > If there's no objection, I'd like to commit it to qt4-moc and remove all > > patches added in the revisions above that wrap Boost includes within #ifndef > > Q_MOC_RUN blocks. > > I'm ok with that, however it'll require an exp-run. Do you mean an exp-run with the existing ports tree and Boost 1.55 or another exp-run by truckman@ with a tree using Boost 1.60?
Any kind of exp-run with moc patch is needed before committing the patch. Anyway, I plan to start preparing cumulative boost update patch which will include all patches not committed to the tree yet as well as rollbacks of patches not needed with this moc patch. Exp-run with that patch will test both the moc, all the fixes and rollbacks.
(In reply to Don Lewis from comment #45) > Created attachment 166861 [details] > updated patch to upgrade to boost 1.60 (and also add long double support for > recent FreeBSD) > > Fix boost-docs pkg-plist. > > Strip lib/libboost_python.so. Don, with the lastest patch on 10-amd64: ===> Building package for boost-libs-1.60.0 pkg-static: Unable to access file /wrkdirs/usr/ports/devel/boost-libs/work/stage/usr/local/lib/libboost_math_c99l.a: No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/devel/boost-libs/work/stage/usr/local/lib/libboost_math_c99l.so: No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/devel/boost-libs/work/stage/usr/local/lib/libboost_math_c99l.so.1.60.0: No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/devel/boost-libs/work/stage/usr/local/lib/libboost_math_c99l.so.5: No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/devel/boost-libs/work/stage/usr/local/lib/libboost_math_tr1l.a: No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/devel/boost-libs/work/stage/usr/local/lib/libboost_math_tr1l.so: No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/devel/boost-libs/work/stage/usr/local/lib/libboost_math_tr1l.so.1.60.0: No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/devel/boost-libs/work/stage/usr/local/lib/libboost_math_tr1l.so.5: No such file or directory *** Error code 1
(In reply to Dmitry Marakasov from comment #54) I'm not seeing that here, even after upgrading the ports tree from r405759, which is what I originally used to generate and test the patch, to r409705. I tested with 10.1-RELEASE-p27 amd64. No problems with 10.3-PRERELEASE r295020, either. The actual error is happening earlier. It looks like something is preventing the math libraries from building. Are you using any non-default options or CFLAGS?
(In reply to Don Lewis from comment #55) > I'm not seeing that here, even after upgrading the ports tree from r405759, > which is what I originally used to generate and test the patch, to r409705. > I tested with 10.1-RELEASE-p27 amd64. No problems with 10.3-PRERELEASE > r295020, either. Right, I've lost a boost patch related to long double support, with it it does build fine.
(In reply to Raphael Kubo da Costa from comment #52) I only tested ports that directly depend on boost.
Created attachment 167562 [details] Cumulative boost 1.60 update + consumer fixes Here, I think I've managed to put it all together. I've tested it in poudriere on truckman's failure list + some extra ports. Summary: - boost update to 1.60 (unmodified https://bugs.freebsd.org/bugzilla/attachment.cgi?id=166861) - qt4-moc patch (https://bugs.freebsd.org/bugzilla/attachment.cgi?id=167007 + portrevision bump) - consumer port fixes not committed yet - databases/mariadb55-server - databases/mariadb100-server - graphics/mapnik - graphics/py-openimageio (through graphics/openimageio) - some second-tier updates (updates required by updates required by boost update) - astro/viking (blocks mapnik update) - graphics/openshadinglanguage (blocks openimageio update) - graphics/luxrender (blocks openimageio update) - couple of ports marked BROKEN - games/plee-the-bear (my port, will deal with it separately) - textproc/libe-book00, textproc/libvisio (they are deprecated anyway, fixes rejected) - several rollbacks of moc-related fixes (#ifndef Q_MOC_RUN) which are no longer needed with proper qt4-moc patch - audio/clementine-player - cad/openscad - graphics/aqsis - graphics/evolvotron - multimedia/gstreamer-qt4 - net-p2p/namecoin - science/avogadro - math/pdal fixed by switching to bundled boost First of all, I'd like to request an exp-run for this patch. It'll confirm there are no other boost failures left and qt4-moc update doesn't introduce additional problems. Next, I plan to commit all consumer and consumer of consumer fixes this week, they are mainly pending maintainer timeouts. Finally, I'd like someone to comment on when we can commit this WRT 10.3-RELEASE. My idea is that it can only hit the tree after the release.
Created attachment 167564 [details] Cumulative boost 1.60 update + consumer fixes (Reupload the patch with correct mime type)
Note about cad/kicad: trying to upgrade this port to the latest (4.0.2 ATM), it fails with an error caused by boost::hash. Upstream says to upgrade boost to at least 1.56.
Created attachment 167577 [details] Cumulative boost 1.60 update + consumer fixes Added databases/akonadi fix on 9.x (see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207600)
Requesting an exp-run of latest cumulative patch https://bugs.freebsd.org/bugzilla/attachment.cgi?id=167577 on 10.x and 9.x.
Looks like we've been making progress. With ports tree r409795 and my newest boost 1.60 patch on FreeBSD 10 amd64: Failed: 17 Skipped: 5 Ignored: 11 The failed ports were: databases/mariadb100-server:build (fix not committed yet) databases/mariadb101-server:build (new) databases/mariadb55-server:package (fix not committed yet) deskutils/kdepim4:build devel/kdevplatform:build dns/bundy:build (new) editors/libreoffice4:build (returned) games/plee-the-bear:build graphics/mapnik:build (fix not committed yet) graphics/py-openimageio:build (fix not committed yet) graphics/scantailor:build (patch committed r408592, still failing) math/pdal:build (switch to bundled boost) multimedia/gstreamer1-qt4:build security/quantis:build textproc/libe-book00:build (deprecated) textproc/libvisio:build (deprecated) x11/leeccraft:build This did not include the qt4-moc patch, which may fix some of the remaining failures. Build failure logs here: https://people.freebsd.org/~truckman/boost-1.60_fallout/r409795/FreeBSD-10.1-amd64/ I'll try to try to test the combined patch, but adding build tests for things that depend on qt4-moc adds a lot more ports to test.
I think 10.x is ok, but 9.x will require some more attention. At least boost + compiler:c++11-lang pattern is error prone, I've already fixed databases/akonadi, then devel/liborcus (not yet included in the patch), and I've got failures for dns/bundy and editors/libreoffice4.
With the cumulative patch, ports tree r409795, the following in make.conf: OPTIONS_SET=REGEX OQGRAPH BOOST MOD_BOOLEAN ASIO MNUMPY DISABLE_VULNERABILITIES=yes and building all the ports that depend on boost-libs and the other ports modified by the patch, the only breakage that I see on FreeBSD 10.1 amd64 is: dns/bundy:build databases/mariadb101-server:build editors/libreoffice4:build The OQGRAPH_USE option in mariadb101-server should be marked as broken on FreeBSD >= 10. Even if the build managed to succeed, the resulting executable would segfault on startup because mixing: OQGRAPH_USE= gcc=yes to compile the port with g++ and then linking it to libboost_system.so which is compiled with the base clang++ is a fatal combination.
(In reply to Dmitry Marakasov from comment #64) Problems with boost + compiler:c++11-lang on FreeBSD 9 should not be new other than in ports that were patched to add -lboost_system for compatibility with the new version of boost. This generally doesn't show up at build time, but rather as a fatal runtime problem. On FreeBSD 9, this will cause the port to be build with clang34++ from ports, which causes linkage to the version of libc++ from ports, whereas boost is compiled with the base c++ compiler (normally g++ on FreeBSD 9), and is linked to the base libstdc++. Mixing these two libraries in the same executable is fatal. Tweaking the port to use c++11-lib is likely to work better since it will use the default ports version of gcc to compile the port. That will usually work as long as the runtime linker pulls in the version of libstdc++ bundled with the ports gcc rather than the version of libstdc++ in base.
(In reply to Don Lewis from comment #66) > On FreeBSD 9, this will cause the port to be build with clang34++ from ports, > which causes linkage to the version of libc++ from ports, whereas boost is > compiled with the base c++ compiler (normally g++ on FreeBSD 9), and is linked > to the base libstdc++. It is not true. 9.3 is the oldest supported version and it has LLVM/Clang 3.4.
(In reply to Don Lewis from comment #66) > Problems with boost + compiler:c++11-lang on FreeBSD 9 should not be new other > than in ports that were patched to add -lboost_system for compatibility with > the new version of boost. BTW, adding '-lboost_system' to LDFLAGS is usually not necessary. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207015#c2 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207016#c2
(In reply to Jung-uk Kim from comment #67) >> On FreeBSD 9, this will cause the port to be build with clang34++ from ports, >> which causes linkage to the version of libc++ from ports, whereas boost is >> compiled with the base c++ compiler (normally g++ on FreeBSD 9), and is linked > to the base libstdc++. > > It is not true. 9.3 is the oldest supported version and it has LLVM/Clang 3.4. If that's the case I think things should work since I think the base clang in 9.3 links with libstdc++. Someone can still break it though if they build their system without clang.
(In reply to Jung-uk Kim from comment #68) > BTW, adding '-lboost_system' to LDFLAGS is usually not necessary. That's good to know!
(In reply to Jung-uk Kim from comment #68) > > BTW, adding '-lboost_system' to LDFLAGS is usually not necessary. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207015#c2 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207016#c2 That doesn't seem to be compatible with boost 1.55.0. I tried the fix for libreoffice4 and got this failure: In file included from /wrkdirs/usr/ports/editors/libreoffice4/work/libreoffice-4.3.7.2/sc/qa/unit/helper/qahelper.cxx:10: In file included from /wrkdirs/usr/ports/editors/libreoffice4/work/libreoffice-4.3.7.2/sc/qa/unit/helper/qahelper.hxx:14: In file included from /wrkdirs/usr/ports/editors/libreoffice4/work/libreoffice-4.3.7.2/sc/qa/unit/helper/debughelper.hxx:27: In file included from /usr/local/include/mdds/mixed_type_matrix.hpp:33: In file included from /usr/local/include/mdds/mixed_type_matrix_storage.hpp:39: In file included from /usr/local/include/boost/pool/object_pool.hpp:18: In file included from /usr/local/include/boost/pool/poolfwd.hpp:24: In file included from /usr/local/include/boost/pool/detail/mutex.hpp:14: In file included from /usr/local/include/boost/thread/mutex.hpp:16: In file included from /usr/local/include/boost/thread/pthread/mutex.hpp:12: In file included from /usr/local/include/boost/thread/exceptions.hpp:22: In file included from /usr/local/include/boost/system/system_error.hpp:14: /usr/local/include/boost/system/error_code.hpp:516:13: fatal error: 'boost/../libs/system/src/error_code.cpp' file not found # include <boost/../libs/system/src/error_code.cpp> ^ The problem is that error_code.hpp contains: # ifdef BOOST_ERROR_CODE_HEADER_ONLY # include <boost/../libs/system/src/error_code.cpp> # endif and error_code.cpp is not installed. I think this was fixed in boost 1.56.0.
Created attachment 168130 [details] updated patch to upgrade to boost 1.60 (and also add long double support for recent FreeBSD) Update patch to upgrade boost to 1.60 to revert addition of boost-libs/files/patch-bae401b1eb0594932c4e780d496cba852c23b75f by r411050 as this commit is already part of boost 1.60. See <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207429>.
Is this ready for exp-run ? what is the good patch (there are 6 non obsolete patches) ?
Not yet: * The mariadb patches have not yet been committed. * The qt4-moc patch has not yet been committed. * There may be other patches in the cumulative patch that should be committed. * I don't believe we have a fix for dns/bundy * I'm looking into the FreeBSD 9.x issues. I'm currently testing a patch to boost to fix databases/akonadi. libreoffice4 is a chicken vs. egg problem. My patch to fix it breaks it with boost 1.55. Obviously we can ignore the patches to upgrade to 1.58 and 1.59. I believe the www/anyterm patch has been committed. The "updated patch to upgrade boost to 1.60 ..." patch is the latest one to upgrade boost itself, but there may be other changes for the FreeBSD 9.x issues. The cumulative patch included an older version of the boost patch and needs to be regenerated to bring it up to date for the latest boost changes and probably for other changes that have been committed to other ports.
(In reply to Don Lewis from comment #74) > * The qt4-moc patch has not yet been committed. I was told in comment #50 that you guys would like an exp-run for this change, and in comment #53 it was indicated you guys would prefer to test it with the rest of the required changes instead of landing this separately and before the rest. > * I'm looking into the FreeBSD 9.x issues. I'm currently > testing a patch to boost to fix databases/akonadi. I'm waiting for replies to my comment in bug 207600. Please keep kde@ in the loop for changes in akonadi.
(In reply to Raphael Kubo da Costa from comment #75) > I'm waiting for replies to my comment in bug 207600. Please keep kde@ in the > loop for changes in akonadi. It appears possible to patch boost so that akonadi builds without any further changes. --- boost/config/compiler/clang.hpp.orig 2015-12-08 18:55:19 UTC +++ boost/config/compiler/clang.hpp @@ -167,7 +167,7 @@ # define BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX #endif -#if !__has_feature(cxx_rvalue_references) +#if !__has_feature(cxx_rvalue_references) || (defined(__GLIBCXX__) && __GLIBCXX__ < 20080606) # define BOOST_NO_CXX11_RVALUE_REFERENCES #endif devel/liborcus runs into the same problem, but the above patch is not sufficient. It relies on one of a number of c++ headers having already been included in order to bring in <bits/c++config.h> so that __GLIBCXX__ gets defined. The liborcus source is OK, but configure has a problem and thinks that <boost/filesystem/path.hpp> is not usable. The following ugly patch to configure fixes that: --- configure.orig 2015-06-18 23:43:37 UTC +++ configure @@ -18668,7 +18668,8 @@ ac_link='$CXX -o conftest$ac_exeext $CXX ac_compiler_gnu=$ac_cv_cxx_compiler_gnu boost_save_CPPFLAGS=$CPPFLAGS CPPFLAGS="$CPPFLAGS $BOOST_CPPFLAGS" -ac_fn_cxx_check_header_mongrel "$LINENO" "boost/filesystem/path.hpp" "ac_cv_header_boost_filesystem_path_hpp" "$ac_includes_default" +ac_fn_cxx_check_header_mongrel "$LINENO" "boost/filesystem/path.hpp" "ac_cv_header_boost_filesystem_path_hpp" "$ac_includes_default +#include <ios>" if test "x$ac_cv_header_boost_filesystem_path_hpp" = xyes; then : $as_echo "#define HAVE_BOOST_FILESYSTEM_PATH_HPP 1" >>confdefs.h @@ -18720,6 +18721,7 @@ else # Generate the test file. cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ +#include <ios> #include <boost/filesystem/path.hpp> int Does this look like a reasonable direction to take?
Do you have a link where I can see the full errors you're getting? It's not clear to me why you're going for __GLIBCX__: detecting libstdc++'s version is a royal pain in the ass and IIRC the __GLIBCXX__ macro was not very precise in determining which version it corresponds to. You might want to take a look at what we do in Qt4 (devel/qt4/files/extrapatch-src-corelib-global-qglobal.h) and Qt5 (devel/qt5/files/extrapatch-src_corelib_global_qcompilerdetection.h): * In Qt4 we only enable support for initializer lists (which must be supported by both the compiler and the standard library) with clang if and only if it's being used with libc++, under the assumption that clang and libstdc++ generally means it's FreeBSD 9 with clang and base libstdc++. We verify that by including a header that does nothing (ciso646) and then checking if that indirectly defined _LIBCPP_VERSION. * In Qt5 we do pretty much the same thing, but extend the check for other features that are probably used by boost too.
The error is listed in the first comment to PR 207600. Something like what your are doing for Qt4 might also work, but FreeBSD 9 doesn't have <ciso646>. Where does _LIBCPP_VERSION get defined?
(In reply to Don Lewis from comment #78) > The error is listed in the first comment to PR 207600. I meant the error you're getting with liborcus, not akonadi. > Something like what your are doing for Qt4 might also work, but FreeBSD 9 > doesn't have <ciso646>. It does, it's a standard C++ header. On ref9-amd64.freebsd.org, for example, it's in /usr/include/c++/4.2/ciso646. > Where does _LIBCPP_VERSION get defined? In /usr/include/c++/v1/__config (if you have libc++ installed). It is included by other headers shipped by libc++, including ciso646.
liborcus fails with the same error, but in configure. Configure tries to compile a test program that is basically #include <boost/filesystem/path.hpp> which ends up including <boost/bind/bind.hpp> resulting in the same breakage as seen with akonadi. My boost patch doesn't fix that because none of the stdc++ headers that result in __GLIBCXX__ getting defined have been included at that point. I kind of hate to do a #include inside clang.hpp because of the extra pollution, but that might be the best way forward. That would fix liborcus as well as akonadi. Both liborcus and akonadi compile with this patch applied to boost: --- boost/config/compiler/clang.hpp.orig 2015-12-08 18:55:19 UTC +++ boost/config/compiler/clang.hpp @@ -169,6 +169,14 @@ #if !__has_feature(cxx_rvalue_references) # define BOOST_NO_CXX11_RVALUE_REFERENCES +#else +/* + * Workaround for clang on FreeBSD 9.x using ancient libstdc++. + */ +# include <ciso646> +# if !defined(_LIBCPP_VERSION) +# define BOOST_NO_CXX11_RVALUE_REFERENCES +# endif #endif #if !__has_feature(cxx_strong_enums)
Fixing dns/bundy will not be fun. See <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207982>
Created attachment 168185 [details] updated patch to upgrade to boost 1.60 (and also add long double support for recent FreeBSD) Update the boost 1.60 upgrade patch with an extra patch, files/patch-boost_config_compiler_clang.hpp, to handle the lack of complete c++11 support on FreeBSD 9.x when building consumers with base clang and libstdc++ bundled with base gcc. This is a variant of my patch from comment #80 that make it more convenient to disable other features on FreeBSD 9.x if needed.
For an exp-run, I think you'd want to apply these patches from this PR: https://bugs.freebsd.org/bugzilla/attachment.cgi?id=168185 (updated patch to upgrade to boost 1.60 (and also add long double support for recent FreeBSD) https://bugs.freebsd.org/bugzilla/attachment.cgi?id=167007 (devel/qt4-moc patch with additional Boost include guards) as well as the patches from these PRs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207094 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207115 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207675 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207697 The fix for anyterm has already been committed. The gstream1-qt4 issue should be fixed by the above patch. databases/akonadi and devel/liborcus should be fixed by the latest version of the boost patch. Expect dns/bundy to break. Anything else?
It's not required to run this PR, but just make sure the ports mentioned in comment #49 have their unnecessary changes reverted before/when landing.
(In reply to Raphael Kubo da Costa from comment #49) > This attachment contains a patch to devel/qt4-moc that defines more include > guards so that the Boost 1.60 headers that include the headers moc can't parse > (basically, any header that uses macros in a namespace declaration) are > skipped. I was able to build all ports in > https://wiki.freebsd.org/BoostPortingProject/1.55-to-1.60 that were failing > because of moc without having to patch any of them at all (basically reverting > most of ports r408472, ports r408473, ports r408474, ports r408475, ports > r408502, ports r408773, ports r408419, but also including all ports with a > column saying "fixed by qt4-moc patch"). > > If there's no objection, I'd like to commit it to qt4-moc and remove all > patches added in the revisions above that wrap Boost includes within #ifndef > Q_MOC_RUN blocks. Is there any reason that we shouldn't do an exp-run and commit this before doing the boost upgrade exp-run? That would reduce the number of moving parts for the boost upgrade.
(In reply to Don Lewis from comment #85) I don't have any objections to that -- it just wasn't clear to me at the time if you would drive the exp-run, or if I should ask for it, or whether you'd prefer to just land everything at once (plus comment #53 mentioned everything would be at least tested all at once). I'm definitely in favor of smaller patches, so let me know if you need help with the qt4-moc exp-run.
(In reply to Raphael Kubo da Costa from comment #86 It looks like Dmitry handled the last exp-run. If the qt4-moc patch doesn't require the new boost, then I think it should get committed before the the boost exp-run. Probably the least confusing thing to do is to create a new PR for the qt4-moc patch and request an exp-run for that along with the other changes mentioned in comment #49 (or revert them before the exp-run). List that PR as a blocker for this one. If the exp-run looks OK, then commit those changes, and then we can request the boost exp-run which will have a much shorter list of changes to test.
I've finally filed bug 208233 for the qt4-moc exp-run. The patch I'm testing also removes all the obscure patches I mentioned in comment #49 (leaving only a handful that did not add #ifndef Q_MOC_RUN bits).
A commit references this bug: Author: rakuco Date: Thu Mar 24 10:31:07 UTC 2016 New revision: 411765 URL: https://svnweb.freebsd.org/changeset/ports/411765 Log: qt4-moc: Add more Boost include guards to moc's definition list. In preparation for updating Boost to 1.60, add include guards from more Boost headers to the list of macros that moc automatically defines when processing files. As explained in r408911, Qt4's moc cannot parse some constructs used by a few Boost headers, so we define their include guards to make moc skip them. This is a cleaner approach that allows us to largely revert r408472, r408473, r408474, r408475, r408502, r408773 and r408419, which added several patches to many ports to work around this moc bug. PR: 199601 PR: 208322 Changes: head/audio/clementine-player/files/patch-src_core_mergedproxymodel.h head/audio/clementine-player/files/patch-src_library_groupbydialog.h head/cad/openscad/files/ head/devel/qt4-moc/files/patch-src__tools__moc__main.cpp head/graphics/aqsis/files/patch-include_aqsis_tex_buffers_channellist.h head/graphics/aqsis/files/patch-include_aqsis_tex_buffers_mixedimagebuffer.h head/graphics/aqsis/files/patch-include_aqsis_util_socket.h head/graphics/aqsis/files/patch-tools_piqsl_displayserverimage.cpp head/graphics/aqsis/files/patch-tools_piqsl_image.h head/graphics/evolvotron/files/patch-libfunction_useful.h head/multimedia/gstreamer-qt4/files/ head/net-p2p/namecoin/files/patch-src_allocators.h head/net-p2p/namecoin/files/patch-src_qt_guiutil.h head/net-p2p/namecoin/files/patch-src_util.h head/science/avogadro/files/patch-libavogadro_src_pythonengine__p.h head/science/avogadro/files/patch-libavogadro_src_pythonextension__p.h head/science/avogadro/files/patch-libavogadro_src_pythoninterpreter.h head/science/avogadro/files/patch-libavogadro_src_pythonscript.h head/science/avogadro/files/patch-libavogadro_src_pythontool__p.h
So qt4-moc has been fixed. I guess the next step is following comment #83? Don, will you take care of it?
Should we use the custom make.conf settings or not? It is easier to compare the exp-run results to the unpatched results if we leave make.conf alone, though we do lose some coverage. If we use the stock make.conf, then we could omit the mariadb patches since these ports don't use boost with their default option settings.
Comment on attachment 162139 [details] updated patch to upgrade to boost 1.58 We won't be updating boost to 1.58, so mark the patch to do so as obsolete.
Comment on attachment 162140 [details] patch to upgrade to boost 1.59 (and also add long double support for recent FreeBSD) We won't be upgrading boost to version 1.59, so mark this patch as obsolete.
Comment on attachment 162140 [details] patch to upgrade to boost 1.59 (and also add long double support for recent FreeBSD) Actually mark the boost 1.59 patch as obsolete
The more coverage, the better, but if we know that a port like mariadb will cause a lot of other ports to be skipped then I guess we can make do with the stock make.conf.
(In reply to Raphael Kubo da Costa from comment #95) I don't know what other ports depend on them, but I do know they didn't build with OQGRAPH enabled, even with boost 1.55. For the exp-run, I think we can get away with just the boost patch and the libreoffice4 patch.
Created attachment 168588 [details] combined boost 1.60 upgrade and libreoffice4 fix for boost 1.60 patch Combine the updated patch to upgrade boost 1.60 and the patch to fix the libreoffice4 build from bug #207697 with 1.60 into a single patch for the exp-run.
Perhaps it's a good idea to file a new bug for the exp-run, I'm not sure if antoine is reading all the comments here.
Comment on attachment 167007 [details] devel/qt4-moc patch with additional Boost include guards Obsolete: committed in ports r411765
Comment on attachment 165706 [details] Patch for www/anyterm to work with boost 1.60 Obsolete: committed in ports r408416
A commit references this bug: Author: rakuco Date: Mon Mar 28 19:33:13 UTC 2016 New revision: 412070 URL: https://svnweb.freebsd.org/changeset/ports/412070 Log: Remove expired ports. 2016-03-26 textproc/libvisio: Not used any more 2016-03-26 textproc/libe-book00: Not used any more Not only do these two ports have newer versions in the tree (textproc/libvisio01 and textproc/libe-book, respectively), but they were failing to build with the upcoming Boost 1.60. PR: 199601 Changes: head/MOVED head/textproc/Makefile head/textproc/libe-book00/ head/textproc/libvisio/
2 new failures: + {"origin"=>"dns/bundy", "pkgname"=>"bundy-0.20160125_2", "phase"=>"build", "errortype"=>"clang"} + {"origin"=>"games/plee-the-bear", "pkgname"=>"plee-the-bear-0.6.0_7", "phase"=>"build", "errortype"=>"clang"} 4 extra failures on FreeBSD 9.3: + {"origin"=>"devel/liblas", "pkgname"=>"liblas-1.8.0", "phase"=>"build", "errortype"=>"bad_C++_code"} + {"origin"=>"graphics/gnash", "pkgname"=>"gnash-0.8.10_16", "phase"=>"build", "errortype"=>"bad_C++_code"} + {"origin"=>"multimedia/aegisub", "pkgname"=>"aegisub-3.2.2_2", "phase"=>"build", "errortype"=>"new_compiler_error"} + {"origin"=>"net/kea", "pkgname"=>"kea-1.0.0", "phase"=>"build", "errortype"=>"???"} 1 extra failure on FreeBSD head: + {"origin"=>"sysutils/freefilesync", "pkgname"=>"freefilesync-7.9", "phase"=>"build", "errortype"=>"???"} Failure logs: http://package18.nyi.freebsd.org/data/101amd64-default-PR199601/2016-03-26_20h35m15s/logs/errors/bundy-0.20160125_2.log http://package18.nyi.freebsd.org/data/101amd64-default-PR199601/2016-03-26_20h35m15s/logs/errors/plee-the-bear-0.6.0_7.log http://package18.nyi.freebsd.org/data/93amd64-default-PR199601/2016-03-27_07h21m35s/logs/errors/liblas-1.8.0.log http://package18.nyi.freebsd.org/data/93amd64-default-PR199601/2016-03-27_07h21m35s/logs/errors/gnash-0.8.10_16.log http://package18.nyi.freebsd.org/data/93amd64-default-PR199601/2016-03-27_07h21m35s/logs/errors/aegisub-3.2.2_2.log http://package18.nyi.freebsd.org/data/93amd64-default-PR199601/2016-03-27_07h21m35s/logs/errors/kea-1.0.0.log http://package18.nyi.freebsd.org/data/headamd64-default-PR199601/2016-03-27_19h52m41s/logs/errors/freefilesync-7.9.log
Thanks for all your efforts. I just wanted to leave a comment: I installed devel/boost-all from ports today in order to build Hadouken: https://github.com/hadouken/hadouken Boost is missing a file: http://www.boost.org/doc/libs/1_56_0/boost/core/null_deleter.hpp VS. http://www.boost.org/doc/libs/1_55_0/boost/core/null_deleter.hpp Manas
(In reply to Manas B from comment #103) > Boost is missing a file: > http://www.boost.org/doc/libs/1_56_0/boost/core/null_deleter.hpp > > VS. > > http://www.boost.org/doc/libs/1_55_0/boost/core/null_deleter.hpp I'm not entirely sure what you mean by missing; from the looks of it it just appears that this header did not exist before Boost 1.56.
*** Bug 208812 has been marked as a duplicate of this bug. ***
After three months without any viewable progress: What is the current state of this update?
I think it has stalled (I haven't worked on it for these past three months). We need someone with enough time to pick this up and continue fixing all ports until we're ready to go.
If someone did want to help out resolving this bug, how does one get a list of what needs to be fixed (beyond what's listed above)? Is there a system that can be used to do port builds to make sure everything that uses boost works?
The ports listed in #102 should be the complete list, unless something else broke in the meantime. I do know that dns/bundy has already been fixed. If we can get the other ports fixed, then we can request another exp-run. That will try to build everything for multiple FreeBSD versions, and the results will be compared to builds without the boost upgrade. For my initial work, I made a list of just the ports that referenced boost in BUILD_DEPENDS and LIB_DEPENDS. That's about 300 ports. With their dependencies thrown in, the total number of ports that need to be built is a bit over 1000. I've got an 8 core machine that I use for package building, and it took between one and two days to build those ports for FreeBSD 10 amd64.
Is there any update on this? I'd like a later boost for arm64 support as it's blocking a few hundred ports from building.
Do we have a list of ports that actually break with boost 1.60 ?
(In reply to Johannes Jost Meixner from comment #111) See comment #102, though dns/bundy was subsequently fixed.
FYI: To make this more accessible for testing, I applied the patches (with some difficulty) and imported the boost 1.60 ports into my wip collection: https://github.com/outpaddling/freebsd-ports-wip
Come on guys, no news about this update? Boost is now on version 1.62
FYI, I renamed the 1.60.0 ports at https://github.com/outpaddling/freebsd-ports-wip to boost*-1.60.0 and have begun upgrading to 1.62.0. Also switched from tar:bzip2 to 7z as the distfiles are smaller.
Can anyone make a list of ports where it is used boost? I have enough time to test them all.
Created attachment 175960 [details] script to find ports that use boost I used the attached script to find ports that directly use boost. The make.conf referenced by the script contains: OPTIONS_SET=REGEX OQGRAPH BOOST MOD_BOOLEAN ASIO MNUMPY DISABLE_VULNERABILITIES=yes to set some non-default options to detect some ports that don't use boost in their default configuration. I seem to recall that building the set of ports that this script detects took 16-18 hours on my 8-core package build machine for one arch + OS version combo.
(In reply to Don Lewis from comment #117) Send me an email, i need to ask you some questions. Since i never did any contibute intro ports tree.
I've tested 1.62 in my wip collection (https://github.com/outpaddling/freebsd-ports-wip). No issues with the dependent ports I've tried. BTW, biology/unanimity in that same collection does not build with boost 1.5x.
Created attachment 176923 [details] boost 1.62 + long double fix + libreoffice4 fix (+ commit message) - Update to 1.62 - Drop .so.MAJOR compatibility links Hmm, `long double` fix reminds me of bug 193528 and also checks __FreeBSD_version__ without <sys/param.h> or <osreldate.h>.
approved (with my office@ hat)
Can you do another exp-run on 10.1 and 9.3? Boost 1.62 may have new fallout compared to 1.60.
I think we should make a list with tested ports, i mean.. why should i test over 300 ports if 100 of them is already fixed and tested with new boost version ?
Created attachment 176952 [details] boost 1.62 + misc fixes - "long double" math is now always enabled. It failed to build after injecting synthetic #error on undefined __FreeBSD_version but succeeded as soon as <sys/param.h> or <osreldate.h> was added. Actually disabling it on < 10.2 systems would mean fixing comment 54. - devel/liblas, net/kea are fixed on 9.x via Clang build - biology/seqan-apps + boost 1.62 regression is fixed via upstream (boost)
A commit references this bug: Author: jbeich Date: Sun Nov 13 18:49:42 UTC 2016 New revision: 426061 URL: https://svnweb.freebsd.org/changeset/ports/426061 Log: multimedia/aegisub: simplify + unbreak boost 1.62 on 9.x In file included from libaegisub/ass/time.cpp:20:0: libaegisub/include/libaegisub/format.h: In static member function 'static Out agi::format_detail::runtime_cast_helper<In, Out, <anonymous> >::cast(const In&)': libaegisub/include/libaegisub/format.h:31:37: error: 'bad_cast' is not a member of 'std' static Out cast(In const&) { throw std::bad_cast(); } ^ In file included from libaegisub/lua/script_reader.cpp:19:0: libaegisub/include/libaegisub/file_mapping.h:37:3: error: 'unique_ptr' in namespace 'std' does not name a type std::unique_ptr<boost::interprocess::mapped_region> region; ^ libaegisub/include/libaegisub/file_mapping.h:54:3: error: 'unique_ptr' in namespace 'std' does not name a type std::unique_ptr<boost::interprocess::mapped_region> read_region; ^ libaegisub/include/libaegisub/file_mapping.h:56:3: error: 'unique_ptr' in namespace 'std' does not name a type std::unique_ptr<boost::interprocess::mapped_region> write_region; ^ PR: 199601 Changes: head/multimedia/aegisub/Makefile head/multimedia/aegisub/files/patch-libaegisub__common__cajun__reader.cpp head/multimedia/aegisub/files/patch-libaegisub__common__color.cpp head/multimedia/aegisub/files/patch-libaegisub_common_cajun_reader.cpp head/multimedia/aegisub/files/patch-libaegisub_include_libaegisub_file__mapping.h head/multimedia/aegisub/files/patch-libaegisub_include_libaegisub_format.h head/multimedia/aegisub/files/patch-src__ass_file.cpp head/multimedia/aegisub/files/patch-src__ass_override.cpp head/multimedia/aegisub/files/patch-src__auto4_lua_dialog.cpp head/multimedia/aegisub/files/patch-src__command__edit.cpp head/multimedia/aegisub/files/patch-src__command__recent.cpp head/multimedia/aegisub/files/patch-src__command__video.cpp head/multimedia/aegisub/files/patch-src__dialog_jumpto.cpp head/multimedia/aegisub/files/patch-src__dialog_kara_timing_copy.cpp head/multimedia/aegisub/files/patch-src__dialog_properties.cpp head/multimedia/aegisub/files/patch-src__dialog_shift_times.cpp head/multimedia/aegisub/files/patch-src__dialog_style_editor.cpp head/multimedia/aegisub/files/patch-src__dialog_video_properties.cpp head/multimedia/aegisub/files/patch-src__ffmpegsource_common.cpp head/multimedia/aegisub/files/patch-src__ffmpegsource_common.h head/multimedia/aegisub/files/patch-src__grid_column.cpp head/multimedia/aegisub/files/patch-src__preferences_base.cpp head/multimedia/aegisub/files/patch-src__resolution_resampler.cpp head/multimedia/aegisub/files/patch-src__subs_edit_box.cpp head/multimedia/aegisub/files/patch-src__subs_preview.cpp head/multimedia/aegisub/files/patch-src__subtitle_format_ass.cpp head/multimedia/aegisub/files/patch-src__subtitle_format_srt.cpp head/multimedia/aegisub/files/patch-src__timeedit_ctrl.cpp head/multimedia/aegisub/files/patch-src__validators.cpp head/multimedia/aegisub/files/patch-src__video_out_gl.h head/multimedia/aegisub/files/patch-src__video_provider_ffmpegsource.cpp head/multimedia/aegisub/files/patch-src__visual_tool_rotatexy.cpp head/multimedia/aegisub/files/patch-src__visual_tool_scale.cpp head/multimedia/aegisub/files/patch-src__visual_tool_vector_clip.cpp
Created attachment 176977 [details] boost 1.62 + misc fixes + commit message (rebased against ports r426076) devel/boost-* build fine on DragonFly. In other news: - PORTREVISION bump in consumers - Enforce verbose build per ports r421635 - Convert to _MAKE_ARGS option helper - Drop BOOST_TOOLSET variable - Improve style of do-install a bit (In reply to fcsk.aim from comment #123) > I think we should make a list with tested ports It's down the rabbit hole, see comment 102. Since then new consumers appeared, a few old ones were removed some default options changed. > why should i test over 300 ports if 100 of them is already fixed and > tested with new boost version ? Figuring out what is broken is part of testing. truckman@ provided many examples here how to do it. Only an exp-run may be more accurate. It's currently unknown if 1.62 has any regressions compared to 1.60.
Created attachment 177019 [details] boost 1.62 + misc fixes + commit message (rebased against ports r426166) ports r426143 is cleared to document re-try. It may still fail per bug 213867 comment 1, at least for 11.0.
comment 45 prepended %%PORTDOCS%% which blows up the diff size. Would anyone miss pkg-plist if I used PORTDOCS=* instead? It would mainly help future updates, not this one. # Boost 1.62 $ du -Ah devel/boost-*/pkg-plist 1.9M devel/boost-docs/pkg-plist 586K devel/boost-libs/pkg-plist 512B devel/boost-python-libs/pkg-plist # Boost 1.55 $ du -Ah devel/boost-*/pkg-plist 1.2M devel/boost-docs/pkg-plist 482K devel/boost-libs/pkg-plist 512B devel/boost-python-libs/pkg-plist
Hi folks. Given the amount of time and effort required to coordinate a boost upgrade, due to the logistics of getting all the dependent packages updated in lockstep, is it worth considering splitting up the packaging of libraries into separate "runtime" and "development" parts which can be installed independently? This would permit boost to be upgraded immediately while the dependent packages can catch up over time, and would make it possible to transition much more smoothly. Maybe something to consider for all library packages? This is from someone who packaged shared libraries in Debian for years, where such transitions were routine, so I may have a different perspective on this due to my lack of familiarity with the history of the ports system. Its separation of "library" and "dev" packages allows multiple library versions to be installed concurrently, and one development package. (Boost itself allows multiple header versions to be installed, if you follow the upstream defaults, though it's not too user-friendly on Unix). Is this something which pkg-ng could manage (one source package producing multiple binary packages)? Regards, Roger
Created attachment 177186 [details] boost 1.62 + misc fixes + commit message (rebased against ports r426530) Cosmetic changes: - Re-bump mutual consumers after ports r426525 - Pacify portlint after bumps if DISTVERSIONSUFFIX is defined
New failures on 11.0 i386: + {"origin"=>"dns/powerdns-recursor", "phase"=>"build", "errortype"=>"bad_C++_code"} + {"origin"=>"games/plee-the-bear", "phase"=>"build", "errortype"=>"clang"} + {"origin"=>"graphics/appleseed", "phase"=>"build", "errortype"=>"linker_error"} + {"origin"=>"sysutils/facter", "phase"=>"build", "errortype"=>"clang"} + {"origin"=>"sysutils/freefilesync", "phase"=>"build", "errortype"=>"???"} New failures on 11.0 amd64: + {"origin"=>"dns/powerdns-recursor", "phase"=>"build", "errortype"=>"bad_C++_code"} + {"origin"=>"games/plee-the-bear", "phase"=>"build", "errortype"=>"clang"} + {"origin"=>"sysutils/facter", "phase"=>"build", "errortype"=>"clang"} + {"origin"=>"sysutils/freefilesync", "phase"=>"build", "errortype"=>"???"} Failure logs: http://package18.nyi.freebsd.org/data/110i386-default-PR199601/2016-11-19_20h13m31s/logs/errors/powerdns-recursor-4.0.3_1.log http://package18.nyi.freebsd.org/data/110i386-default-PR199601/2016-11-19_20h13m31s/logs/errors/plee-the-bear-0.6.0_8.log http://package18.nyi.freebsd.org/data/110i386-default-PR199601/2016-11-19_20h13m31s/logs/errors/appleseed-1.5.2.b_1.log http://package18.nyi.freebsd.org/data/110i386-default-PR199601/2016-11-19_20h13m31s/logs/errors/facter-3.1.3_2.log http://package18.nyi.freebsd.org/data/110i386-default-PR199601/2016-11-19_20h13m31s/logs/errors/freefilesync-8.3_1.log
A commit references this bug: Author: jbeich Date: Mon Nov 21 06:52:27 UTC 2016 New revision: 426693 URL: https://svnweb.freebsd.org/changeset/ports/426693 Log: devel/liblas: unbreak build with boost 1.62 on 9.x In file included from /usr/local/include/boost/atomic/capabilities.hpp:19, from /usr/local/include/boost/atomic/atomic.hpp:19, from /usr/local/include/boost/atomic.hpp:12, from /usr/local/include/boost/thread/pthread/once_atomic.hpp:20, from /usr/local/include/boost/thread/once.hpp:20, from src/../include/liblas/detail/singleton.hpp:49, from src/../include/liblas/header.hpp:54, from src/../include/liblas/reader.hpp:46, from src/../include/liblas/index.hpp:45, from src/../include/liblas/detail/index/indexoutput.hpp:46, from src/detail/index/indexoutput.cpp:43: /usr/local/include/boost/atomic/detail/int_sizes.hpp:137:2: error: #error Boost.Atomic: Failed to determine builtin integer sizes, the target platform is not supported. Please, report to the developers. /usr/local/include/boost/atomic/detail/bitwise_cast.hpp: In function 'To boost::atomics::detail::bitwise_cast(const From&) [with To = long unsigned int, From = void*]': /usr/local/include/boost/atomic/detail/atomic_template.hpp:556: instantiated from here /usr/local/include/boost/atomic/detail/bitwise_cast.hpp:39: warning: missing initializer for member 'boost::atomics::detail::bitwise_cast(const From&) [with To = long unsigned int, From = void*]::<anonymous struct>::to' /usr/local/include/boost/atomic/detail/bitwise_cast.hpp: In function 'To boost::atomics::detail::bitwise_cast(const From&) [with To = void*, From = long unsigned int]': /usr/local/include/boost/atomic/detail/atomic_template.hpp:574: instantiated from here /usr/local/include/boost/atomic/detail/bitwise_cast.hpp:39: warning: missing initializer for member 'boost::atomics::detail::bitwise_cast(const From&) [with To = void*, From = long unsigned int]::<anonymous struct>::to' PR: 199601 Reported by: antoine (via exp-run) Approved by: portmgr blanket Changes: head/devel/liblas/Makefile
A commit references this bug: Author: jbeich Date: Mon Nov 21 06:52:38 UTC 2016 New revision: 426694 URL: https://svnweb.freebsd.org/changeset/ports/426694 Log: net/kea: unbreak build with boost 1.62 on 9.x `_ZZN5boost6system15system_categoryEvE21system_category_const' referenced in section `.text' of .libs/libkea_asiolink_la-io_address.o: defined in discarded section `.bss._ZZN5boost6system15system_categoryEvE21system_category_const[_ZZN5boost6system15system_categoryEvE21system_category_const]' of .libs/libkea_asiolink_la-io_address.o `_ZZN5boost6system16generic_categoryEvE22generic_category_const' referenced in section `.text' of .libs/libkea_asiolink_la-io_address.o: defined in discarded section `.bss._ZZN5boost6system16generic_categoryEvE22generic_category_const[_ZZN5boost6system16generic_categoryEvE22generic_category_const]' of .libs/libkea_asiolink_la-io_address.o [...] PR: 199601 Reported by: antoine (via exp-run) Approved by: portmgr blanket Changes: head/net/kea/Makefile
Created attachment 177226 [details] boost 1.62 + misc fixes + commit message (rebased against ports r426695) (In reply to Antoine Brodin from comment #132) > New failures on 11.0 i386: > > + dns/powerdns-recursor Fixed by ports r426688. Attachment 177223 [details] helps fix runtime on amd64 but not i386. I can't debug as the stacktrace is unreadable for some reason (/head + drm-next-4.7 @ amd64 host here). > + games/plee-the-bear Unblocked by maintainer per bug 214516 comment 1. > + graphics/appleseed Fixed by ports r426695. > + sysutils/facter Fixed by ports r426627. > + sysutils/freefilesync Fixed by ports r426687.
Created attachment 177255 [details] boost 1.62 + misc fixes + commit message (rebased against ports r426773) multimedia/aegisub failed to build on FreeBSD 9.3 amd64 because devel/boost-libs disabled ICU at configure. Fixed by dropping LD_LIBRARY_PATH=/usr/lib32 poisonous goo. Clang builds (or 10+ by default) are unaffected. "c++" -L"/usr/local/bin" -L"/usr/local/lib" -Wl,-R -Wl,"/usr/local/bin" -Wl,-R -Wl,"/usr/local/lib" -Wl,-rpath-link -Wl,"/usr/local/bin" -Wl,-rpath-link -Wl,"/usr/local/lib" -o "bin.v2/libs/regex/build/gcc-4.2.1/debug/has_icu" -Wl,--start-group "bin.v2/libs/regex/build/gcc-4.2.1/debug/has_icu_test.o" -Wl,-Bstatic -Wl,-Bdynamic -licudata -licui18n -licuuc -Wl,--end-group -g -m64 testing.unit-test bin.v2/libs/regex/build/gcc-4.2.1/debug/has_icu.passed LD_LIBRARY_PATH="/usr/bin:/usr/lib:/usr/lib32:/usr/lib64:/usr/local/bin:/usr/local/lib:$LD_LIBRARY_PATH" export LD_LIBRARY_PATH "bin.v2/libs/regex/build/gcc-4.2.1/debug/has_icu" && touch "bin.v2/libs/regex/build/gcc-4.2.1/debug/has_icu.passed" /usr/lib32/libm.so.5: unsupported file layout ...failed testing.unit-test bin.v2/libs/regex/build/gcc-4.2.1/debug/has_icu.passed... ...failed updating 1 target...
Hey Jan, is there a chance you could take a few minutes to update the associated Wiki page? https://wiki.freebsd.org/BoostPortingProject/1.55-to-1.60 If only to make obvious what else needs doing and where help is needed, including help testing things. Best -J
(In reply to Johannes Jost Meixner from comment #137) > is there a chance you could take a few minutes to update the associated Wiki > page? I'm not planning to sign up on wiki.f.o yet. Bugzilla works better for tracking progress, see blocking bugs. If you want a sticky *editable* description at the top of a bug try asking our bugmeister@ for "User story" feature. > https://wiki.freebsd.org/BoostPortingProject/1.55-to-1.60 Maybe remove the page itself. Options from comment 27 don't appear to trigger any new bustage on 10.3 amd64. The rest is covered by exp-runs. Boost 1.63.beta.1 currently breaks www/wt (see http://sprunge.us/EBKB ) but otherwise outside of scope for now. graphics/gnash to receive coup de grace because no one cared for 2 years of BROKEN on 10+ systems. Despite upstream being active the last release is from 2012-01-31. Debian gave up and switched to Git snapshots in 2013-09-03 to pick up many fixes, including for Boost 1.60 and FFmpeg 3.x. > If only to make obvious what else needs doing and where help is needed, > including help testing things. Runtime is largely untested except for libreoffice. I've checked a few more due to ENOTIME but only discovered bug 214470 comment 2 so far. Automation is currently lacking because - QAT builds are disabled - poudriere hasn't hooked into ports r398125 yet - many ports don't provide or expose regression tests - some tests need patching to work on FreeBSD
graphics/gnash fails to build on FreeBSD 9.3 (it's already marked BROKEN on FreeBSD 10+): http://package18.nyi.freebsd.org/data/93i386-default-PR199601/2016-11-22_17h24m14s/logs/errors/gnash-0.8.10_19.log Upgrade is fine from portmgr point of view.
A commit references this bug: Author: jbeich Date: Wed Nov 23 12:43:13 UTC 2016 New revision: 426903 URL: https://svnweb.freebsd.org/changeset/ports/426903 Log: devel/boost-libs: always verbose build after r421635 PR: 199601 Approved by: portmgr blanket Changes: head/devel/boost-all/compiled.mk head/devel/boost-libs/Makefile head/devel/boost-python-libs/Makefile
A commit references this bug: Author: jbeich Date: Wed Nov 23 12:43:25 UTC 2016 New revision: 426904 URL: https://svnweb.freebsd.org/changeset/ports/426904 Log: devel/boost-libs: drop old cross-build support after r421583 PR: 199601 Submitted by: bapt Exp-run by: antoine Changes: head/devel/boost-libs/Makefile head/devel/boost-libs/pkg-plist
A commit references this bug: Author: jbeich Date: Wed Nov 23 12:43:37 UTC 2016 New revision: 426905 URL: https://svnweb.freebsd.org/changeset/ports/426905 Log: devel/boost-libs: drop compat links after r322328 PR: 199601 Suggested by: bapt Exp-run by: antoine Changes: head/devel/boost-all/compiled.mk head/devel/boost-libs/Makefile head/devel/boost-libs/pkg-plist head/devel/boost-python-libs/Makefile head/devel/boost-python-libs/pkg-plist
A commit references this bug: Author: jbeich Date: Wed Nov 23 12:43:49 UTC 2016 New revision: 426906 URL: https://svnweb.freebsd.org/changeset/ports/426906 Log: devel/boost-*: better integrate with Mk/* PR: 199601 Submitted by: bapt (based on) Exp-run by: antoine Changes: head/devel/boost-all/compiled.mk head/devel/boost-jam/Makefile head/devel/boost-libs/Makefile head/devel/boost-python-libs/Makefile
A commit references this bug: Author: jbeich Date: Wed Nov 23 12:45:54 UTC 2016 New revision: 426908 URL: https://svnweb.freebsd.org/changeset/ports/426908 Log: devel/boost-*: update to 1.62.0 - Enable `long double` C99 math usage - Switch 9.x back to building with GCC Changes: http://www.boost.org/users/history/ PR: 199601 Submitted by: Chen Xu, bapt, amdmi3, truckman (based on) Reviewed by: rakuco (kde) (earlier version) Exp-run by: antoine (3 tries), truckman (consumers only, earlier versions) Approved by: bapt (office) Changes: head/archivers/innoextract/Makefile head/archivers/tardy/Makefile head/astro/libkgeomap/Makefile head/astro/osmium/Makefile head/audio/ardour/Makefile head/audio/clementine-player/Makefile head/audio/cpp-xmms2/Makefile head/audio/csound6/Makefile head/audio/mp3plot/Makefile head/audio/mumble/Makefile head/audio/murmur/Makefile head/audio/musicpd/Makefile head/audio/ncmpcpp/Makefile head/audio/patchage/Makefile head/audio/pms/Makefile head/audio/py-tagpy/Makefile head/audio/raul/Makefile head/audio/tomahawk/Makefile head/biology/seqan-apps/Makefile head/cad/freecad/Makefile head/cad/fritzing/Makefile head/cad/kicad/Makefile head/cad/kicad-devel/Makefile head/cad/librecad/Makefile head/cad/linuxcnc-devel/Makefile head/cad/openscad/Makefile head/chinese/librime/Makefile head/comms/fldigi/Makefile head/comms/gnuradio/Makefile head/comms/gqrx/Makefile head/comms/gr-osmosdr/Makefile head/comms/uhd/Makefile head/comms/usrp/Makefile head/converters/osm2pgsql/Makefile head/databases/akonadi/Makefile head/databases/galera/Makefile head/databases/glom/Makefile head/databases/hamsterdb/Makefile head/databases/mariadb100-server/Makefile head/databases/mariadb101-server/Makefile head/databases/mariadb55-server/Makefile head/databases/mysql-connector-c++/Makefile head/databases/pgrouting/Makefile head/databases/php5-pdo_cassandra/Makefile head/databases/sfcgal/Makefile head/databases/soci/Makefile head/databases/speedtables/Makefile head/databases/vsqlite/Makefile head/deskutils/easystroke/Makefile head/deskutils/gnote/Makefile head/deskutils/kdepim4/Makefile head/deskutils/kdepim4-runtime/Makefile head/deskutils/kdepimlibs4/Makefile head/deskutils/launchy/Makefile head/deskutils/pinot/Makefile head/devel/avro-cpp/Makefile head/devel/boost-all/common.mk head/devel/boost-all/compiled.mk head/devel/boost-docs/distinfo head/devel/boost-docs/pkg-plist head/devel/boost-jam/Makefile head/devel/boost-jam/distinfo head/devel/boost-libs/Makefile head/devel/boost-libs/distinfo head/devel/boost-libs/files/patch-168e60aa3d5238cd25b341661a6c53e638dd6c33-plusclang head/devel/boost-libs/files/patch-5a9688e4ef22c51f77bf147589e3306bf8fd03df head/devel/boost-libs/files/patch-7d1bf7680301331073761e81b85989b9ecee56d5 head/devel/boost-libs/files/patch-a6b17d900155d2a04f54ad18fd89197001f231ab head/devel/boost-libs/files/patch-bae401b1eb0594932c4e780d496cba852c23b75f head/devel/boost-libs/files/patch-boost-filesystem-str_runtime head/devel/boost-libs/files/patch-boost__archive__iterators__transorm_width.hpp head/devel/boost-libs/files/patch-boost__atomic__detail__cas128strong.hpp head/devel/boost-libs/files/patch-boost__atomic__detail__gcc-atomic.hpp head/devel/boost-libs/files/patch-boost__libs__context__build__Jamfile.v2 head/devel/boost-libs/files/patch-boost__mpl__has_xxx.hpp head/devel/boost-libs/files/patch-boost__multi_array__base.hpp head/devel/boost-libs/files/patch-boost__predef__os__bsd.h head/devel/boost-libs/files/patch-boost__predef__os__bsd__bsdi.h head/devel/boost-libs/files/patch-boost__predef__os__bsd__dragonfly.h head/devel/boost-libs/files/patch-boost__predef__os__bsd__free.h head/devel/boost-libs/files/patch-boost__predef__os__bsd__net.h head/devel/boost-libs/files/patch-boost__predef__os__bsd__open.h head/devel/boost-libs/files/patch-boost__predef__os__macos.h head/devel/boost-libs/files/patch-boost__test__impl__execution_monitor.ipp head/devel/boost-libs/files/patch-boost_config_compiler_clang.hpp head/devel/boost-libs/files/patch-boost_math_tools_config.hpp head/devel/boost-libs/files/patch-boost_math_tools_tuple.hpp head/devel/boost-libs/files/patch-boost_static__assert.hpp head/devel/boost-libs/files/patch-boost_thread_pthread_once.hpp head/devel/boost-libs/files/patch-boost_thread_pthread_once__atomic.hpp head/devel/boost-libs/files/patch-f9b3dcb203f29dff4b264d2430f7dca9ebd43ea6 head/devel/boost-libs/files/patch-tools__build__v2__tools__clang-linux.jam head/devel/boost-libs/files/patch-tools_build_src_tools_clang-linux.jam head/devel/boost-libs/files/patch-tools_build_src_tools_gcc.jam head/devel/boost-libs/pkg-plist head/devel/boost-python-libs/Makefile head/devel/boost-python-libs/distinfo head/devel/boost_build/Makefile head/devel/codeblocks/Makefile head/devel/cpp-netlib/Makefile head/devel/eblob/Makefile head/devel/edb/Makefile head/devel/gearmand/Makefile head/devel/gearmand-devel/Makefile head/devel/guiloader-c++/Makefile head/devel/kdevplatform/Makefile head/devel/libarea/Makefile head/devel/libclaw/Makefile head/devel/libcutl/Makefile head/devel/libflatarray/Makefile head/devel/libftdi/Makefile head/devel/libftdi1/Makefile head/devel/libiqxmlrpc/Makefile head/devel/libkolab/Makefile head/devel/liblas/Makefile head/devel/libopkele/Makefile head/devel/liborcus/Makefile head/devel/liborcus07/Makefile head/devel/log4cxx/Makefile head/devel/love07/Makefile head/devel/love08/Makefile head/devel/love5/Makefile head/devel/luabind/Makefile head/devel/mongo-cxx-driver/Makefile head/devel/monotone/Makefile head/devel/msp430-debug-stack/Makefile head/devel/py-pyopencl/Makefile head/devel/rlvm/Makefile head/devel/sdts++/Makefile head/devel/simgear/Makefile head/devel/smack/Makefile head/devel/srecord/Makefile head/devel/subcommander2/Makefile head/devel/synfig/Makefile head/devel/thrift-cpp/Makefile head/devel/uatraits/Makefile head/devel/umbrello/Makefile head/devel/vera++/Makefile head/devel/xmltooling/Makefile head/devel/yaml-cpp/Makefile head/dns/dnsdist/Makefile head/dns/powerdns/Makefile head/dns/powerdns-recursor/Makefile head/editors/abiword/Makefile head/editors/calligra/Makefile head/editors/libreoffice/Makefile.common head/editors/libreoffice4/Makefile head/editors/madedit/Makefile head/editors/openoffice-4/Makefile head/editors/openoffice-devel/Makefile head/editors/pdfedit/Makefile head/editors/poedit/Makefile head/editors/xmlcopyeditor/Makefile head/emulators/mupen64plus-video-glide64mk2/Makefile head/finance/kmymoney-kde4/Makefile head/finance/ledger/Makefile head/finance/moneymanagerex/Makefile head/ftp/curlpp/Makefile head/games/0ad/Makefile head/games/alephone/Makefile head/games/allacrost/Makefile head/games/arx-libertatis/Makefile head/games/asc/Makefile head/games/bastet/Makefile head/games/blobby/Makefile head/games/burrtools/Makefile head/games/easyrpg-player/Makefile head/games/ember/Makefile head/games/fishsupper/Makefile head/games/flightgear/Makefile head/games/flyhard/Makefile head/games/frogatto/Makefile head/games/galaxyhack/Makefile head/games/glob2/Makefile head/games/lander/Makefile head/games/mkhexgrid/Makefile head/games/openclonk/Makefile head/games/openlierox/Makefile head/games/openmw/Makefile head/games/openyahtzee/Makefile head/games/pingus/Makefile head/games/plee-the-bear/Makefile head/games/pokerth/Makefile head/games/py-fife/Makefile head/games/scummvm-tools/Makefile head/games/spring/Makefile head/games/springlobby/Makefile head/games/supertux2/Makefile head/games/traingame/Makefile head/games/valyriatear/Makefile head/games/vamos/Makefile head/games/vegastrike/Makefile head/games/violetland/Makefile head/games/wesnoth/Makefile head/games/widelands/Makefile head/graphics/agave/Makefile head/graphics/alembic/Makefile head/graphics/appleseed/Makefile head/graphics/aqsis/Makefile head/graphics/blender/Makefile head/graphics/cegui/Makefile head/graphics/digikam-kde4/Makefile head/graphics/enblend/Makefile head/graphics/evolvotron/Makefile head/graphics/fracplanet/Makefile head/graphics/gnash/Makefile head/graphics/gource/Makefile head/graphics/gsculpt/Makefile head/graphics/hugin/Makefile head/graphics/inkscape/Makefile head/graphics/kipi-plugin-gpssync/Makefile head/graphics/libcdr01/Makefile head/graphics/libetonyek01/Makefile head/graphics/libgltf/Makefile head/graphics/libopenraw/Makefile head/graphics/luminance/Makefile head/graphics/luminance-qt5/Makefile head/graphics/luxrender/Makefile head/graphics/mapnik/Makefile head/graphics/mitsuba/Makefile head/graphics/ogre3d/Makefile head/graphics/openimageio/Makefile head/graphics/openshadinglanguage/Makefile head/graphics/panomatic/Makefile head/graphics/povray37/Makefile head/graphics/py-exiv2/Makefile head/graphics/scantailor/Makefile head/graphics/vigra/Makefile head/irc/ezbounce/Makefile head/lang/sdcc/Makefile head/lang/sdcc-devel/Makefile head/mail/libmapi/Makefile head/math/armadillo/Makefile head/math/aspcud/Makefile head/math/cadabra2/Makefile head/math/carve/Makefile head/math/cgal/Makefile head/math/clblas/Makefile head/math/cryptominisat/Makefile head/math/dynare/Makefile head/math/fityk/Makefile head/math/freemat/Makefile head/math/kig/Makefile head/math/liborigin/Makefile head/math/mosesdecoder/Makefile head/math/pdal/Makefile head/math/rocs/Makefile head/math/stp/Makefile head/math/ufc/Makefile head/math/vowpal_wabbit/Makefile head/misc/artikulate/Makefile head/multimedia/aegisub/Makefile head/multimedia/bombono/Makefile head/multimedia/cclive/Makefile head/multimedia/flvtool++/Makefile head/multimedia/gstreamer-qt4/Makefile head/multimedia/gstreamer1-qt4/Makefile head/multimedia/gstreamer1-qt5/Makefile head/multimedia/kodi/Makefile head/multimedia/miro/Makefile head/multimedia/mkvtoolnix/Makefile head/multimedia/omxplayer/Makefile head/multimedia/plexhometheater/Makefile head/multimedia/vdr-plugin-upnp/Makefile head/net/asio/Makefile head/net/cyphesis/Makefile head/net/grive/Makefile head/net/grive2/Makefile head/net/kdenetwork4-strigi-analyzers/Makefile head/net/kea/Makefile head/net/kget/Makefile head/net/libcmis/Makefile head/net/pktanon/Makefile head/net/scribe/Makefile head/net/tcpflow/Makefile head/net/xorp/Makefile head/net-im/ekiga/Makefile head/net-im/licq/Makefile head/net-im/licq-icq/Makefile head/net-im/licq-jabber/Makefile head/net-im/licq-msn/Makefile head/net-im/licq-osd/Makefile head/net-im/licq-qt-gui/Makefile head/net-mgmt/fastnetmon/Makefile head/net-mgmt/icinga2/Makefile head/net-p2p/bitcoin/Makefile head/net-p2p/bitcoin-daemon/Makefile head/net-p2p/bitcoin-utils/Makefile head/net-p2p/digitalcoin/Makefile head/net-p2p/dogecoin/Makefile head/net-p2p/eiskaltdcpp-lib/Makefile head/net-p2p/ktorrent/Makefile head/net-p2p/libktorrent/Makefile head/net-p2p/libtorrent-rasterbar/Makefile head/net-p2p/libtorrent-rasterbar-python/Makefile head/net-p2p/linuxdcpp/Makefile head/net-p2p/litecoin/Makefile head/net-p2p/namecoin/Makefile head/net-p2p/qbittorrent/Makefile head/net-p2p/twister/Makefile head/net-p2p/zetacoin/Makefile head/print/libmspub01/Makefile head/print/libpagemaker/Makefile head/print/lyx/Makefile head/print/pdfcube/Makefile head/print/scribus/Makefile head/science/avogadro/Makefile head/science/bddsolve/Makefile head/science/gromacs/Makefile head/science/orthanc/Makefile head/science/orthanc-dicomweb/Makefile head/science/orthanc-postgresql/Makefile head/science/orthanc-webviewer/Makefile head/science/pulseview/Makefile head/security/botan110/Makefile head/security/clamfs/Makefile head/security/i2pd/Makefile head/security/opensaml2/Makefile head/security/quantis/Makefile head/security/shibboleth2-sp/Makefile head/security/spass/Makefile head/sysutils/condor/Makefile head/sysutils/facter/Makefile head/sysutils/freefilesync/Makefile head/sysutils/fusefs-encfs/Makefile head/sysutils/kf5-kwallet/Makefile head/sysutils/ori/Makefile head/sysutils/osquery/Makefile head/textproc/clucene/Makefile head/textproc/highlight/Makefile head/textproc/kenlm/Makefile head/textproc/libabw/Makefile head/textproc/libe-book/Makefile head/textproc/libkolabxml/Makefile head/textproc/libmwaw03/Makefile head/textproc/libodfgen01/Makefile head/textproc/librevenge/Makefile head/textproc/libvisio01/Makefile head/textproc/libwps/Makefile head/textproc/libwps03/Makefile head/textproc/luceneplusplus/Makefile head/textproc/randlm/Makefile head/textproc/source-highlight/Makefile head/textproc/xmlwrapp/Makefile head/www/anyterm/Makefile head/www/domoticz/Makefile head/www/kdewebdev4/Makefile head/www/nghttp2/Makefile head/www/wt/Makefile head/x11/kde4-workspace/Makefile head/x11/kf5-kactivities/Makefile head/x11/leechcraft/Makefile head/x11-toolkits/flowcanvas/Makefile
A commit references this bug: Author: jbeich Date: Wed Nov 23 12:46:23 UTC 2016 New revision: 426911 URL: https://svnweb.freebsd.org/changeset/ports/426911 Log: graphics/gnash: give up and expire In file included from /usr/local/lib/gcc49/include/c++/bits/stl_algobase.h:65:0, from /usr/local/lib/gcc49/include/c++/list:60, from asobj/flash/display/BitmapData_as.h:24, from asobj/flash/display/BitmapData_as.cpp:21: /usr/local/lib/gcc49/include/c++/bits/stl_iterator_base_types.h: In instantiation of 'struct std::iterator_traits<unsigned int* const>': /usr/local/include/boost/iterator/iterator_traits.hpp:28:74: required from 'struct boost::iterators::iterator_reference<unsigned int* const>' /usr/local/include/boost/iterator/zip_iterator.hpp:90:61: required from 'struct boost::iterators::detail::dereference_iterator::result<boost::iterators::detail::dereference_iterator(unsigned int* const&)>' /usr/local/include/boost/utility/result_of.hpp:189:8: required from 'struct boost::detail::result_of_nested_result<boost::iterators::detail::dereference_iterator, boost::iterators::detail::dereference_iterator(unsigned int* const&)>' /usr/local/include/boost/utility/result_of.hpp:193:8: required from 'struct boost::detail::tr1_result_of_impl<boost::iterators::detail::dereference_iterator, boost::iterators::detail::dereference_iterator(unsigned int* const&), false>' /usr/local/include/boost/utility/detail/result_of_iterate.hpp:27:8: required from 'struct boost::tr1_result_of<boost::iterators::detail::dereference_iterator(unsigned int* const&)>' /usr/local/include/boost/utility/detail/result_of_iterate.hpp:159:8: [ skipping 16 instantiation contexts, use -ftemplate-backtrace-limit=0 to disable ] /usr/local/lib/gcc49/include/c++/bits/stl_algobase.h:398:70: required from '_OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove = false; _II = boost::iterators::zip_iterator<boost::tuples::tuple<unsigned int*, boost::array<double, 2u>*, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> >; _OI = boost::iterators::zip_iterator<boost::tuples::tuple<unsigned int*, boost::array<double, 2u>*, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> >]' /usr/local/lib/gcc49/include/c++/bits/stl_algobase.h:436:38: required from '_OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove = false; _II = boost::iterators::zip_iterator<boost::tuples::tuple<unsigned int*, boost::array<double, 2u>*, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> >; _OI = boost::iterators::zip_iterator<boost::tuples::tuple<unsigned int*, boost::array<double, 2u>*, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> >]' /usr/local/lib/gcc49/include/c++/bits/stl_algobase.h:468:17: required from '_OI std::copy(_II, _II, _OI) [with _II = boost::iterators::zip_iterator<boost::tuples::tuple<unsigned int*, boost::array<double, 2u>*, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> >; _OI = boost::iterators::zip_iterator<boost::tuples::tuple<unsigned int*, boost::array<double, 2u>*, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> >]' asobj/flash/display/BitmapData_as.cpp:412:73: required from 'void gnash::{anonymous}::PerlinNoise<T, Size, Offset>::init(int) [with T = double; unsigned int Size = 256u; unsigned int Offset = 1327u]' asobj/flash/display/BitmapData_as.cpp:310:18: required from 'gnash::{anonymous}::PerlinNoise<T, Size, Offset>::PerlinNoise(int) [with T = double; unsigned int Size = 256u; unsigned int Offset = 1327u]' asobj/flash/display/BitmapData_as.cpp:1371:23: required from here /usr/local/lib/gcc49/include/c++/bits/stl_iterator_base_types.h:165:53: error: 'unsigned int* const' is not a class, struct, or union type typedef typename _Iterator::iterator_category iterator_category; ^ /usr/local/lib/gcc49/include/c++/bits/stl_iterator_base_types.h:166:53: error: 'unsigned int* const' is not a class, struct, or union type typedef typename _Iterator::value_type value_type; ^ /usr/local/lib/gcc49/include/c++/bits/stl_iterator_base_types.h:167:53: error: 'unsigned int* const' is not a class, struct, or union type typedef typename _Iterator::difference_type difference_type; ^ /usr/local/lib/gcc49/include/c++/bits/stl_iterator_base_types.h:168:53: error: 'unsigned int* const' is not a class, struct, or union type typedef typename _Iterator::pointer pointer; ^ /usr/local/lib/gcc49/include/c++/bits/stl_iterator_base_types.h:169:53: error: 'unsigned int* const' is not a class, struct, or union type typedef typename _Iterator::reference reference; ^ In file included from /usr/local/include/boost/fusion/adapted/boost_tuple/detail/convert_impl.hpp:11:0, from /usr/local/include/boost/fusion/adapted/boost_tuple.hpp:20, from /usr/local/include/boost/iterator/zip_iterator.hpp:21, from asobj/flash/display/BitmapData_as.cpp:28: /usr/local/include/boost/fusion/adapted/boost_tuple/detail/build_cons.hpp: In instantiation of 'static boost::fusion::detail::build_tuple_cons<First, Last, false>::type boost::fusion::detail::build_tuple_cons<First, Last, false>::call(const First&, const Last&) [with First = boost::fusion::transform_view_iterator<boost::fusion::boost_tuple_iterator<const boost::tuples::tuple<unsigned int*, boost::array<double, 2u>*, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> >, boost::iterators::detail::dereference_iterator>; Last = boost::fusion::transform_view_iterator<boost::fusion::boost_tuple_iterator<const boost::tuples::null_type>, boost::iterators::detail::dereference_iterator>; boost::fusion::detail::build_tuple_cons<First, Last, false>::type = boost::tuples::cons<unsigned int&, boost::tuples::cons<boost::array<double, 2u>&, bo ost::tuples::null_type> >; typename boost::fusion::detail::build_tuple_cons<typename boost::fusion::result_of::next<Iterator>::type, Last>::type = boost::tuples::cons<boost::array<double, 2u>&, boost::tuples::null_type>; typename boost::fusion::result_of::value_of<First>::type = unsigned int&]': /usr/local/include/boost/fusion/adapted/boost_tuple/detail/convert_impl.hpp:43:87: required from 'static boost::fusion::extension::convert_impl<boost::fusion::boost_tuple_tag>::apply<Sequence>::type boost::fusion::extension::convert_impl<boost::fusion::boost_tuple_tag>::apply<Sequence>::call(Sequence&) [with Sequence = boost::fusion::transform_view<const boost::tuples::tuple<unsigned int*, boost::array<double, 2u>*, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>, boost::iterators::detail::dereference_iterator, boost::fusion::void_>; boost::fusion::extension::convert_impl<boost::fusion::boost_tuple_tag>::apply<Sequence>::type = boost::tuples::cons<unsigned int&, boost::tuples::cons<boost::array<double, 2u>&, boost::tuples::null_type> >]' /usr/local/include/boost/fusion/sequence/convert.hpp:47:29: required from 'typename boost::fusion::result_of::convert<Tag, Sequence>::type boost::fusion::convert(Sequence&) [with Tag = boost::fusion::boost_tuple_tag; Sequence = boost::fusion::transform_view<const boost::tuples::tuple<unsigned int*, boost::array<double, 2u>*, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>, boost::iterators::detail::dereference_iterator, boost::fusion::void_>; typename boost::fusion::result_of::convert<Tag, Sequence>::type = boost::tuples::cons<unsigned int&, boost::tuples::cons<boost::array<double, 2u>&, boost::tuples::null_type> >]' /usr/local/include/boost/iterator/zip_iterator.hpp:214:44: required from 'static reference boost::iterators::detail::converter<reference>::call(Seq) [with Seq = boost::fusion::transform_view<const boost::tuples::tuple<unsigned int*, boost::array<double, 2u>*, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>, boost::iterators::detail::dereference_iterator, boost::fusion::void_>; reference = boost::tuples::cons<unsigned int&, boost::tuples::cons<boost::array<double, 2u>&, boost::tuples::null_type> >]' /usr/local/include/boost/iterator/zip_iterator.hpp:289:42: required from 'typename boost::iterators::detail::zip_iterator_base<IteratorTuple>::type::reference boost::iterators::zip_iterator<IteratorTuple>::dereference() const [with IteratorTuple = boost::tuples::tuple<unsigned int*, boost::array<double, 2u>*, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>; typename boost::iterators::detail::zip_iterator_base<IteratorTuple>::type::reference = boost::tuples::cons<unsigned int&, boost::tuples::cons<boost::array<double, 2u>&, boost::tuples::null_type> >]' /usr/local/include/boost/iterator/iterator_facade.hpp:549:32: required from 'static typename Facade::reference boost::iterators::iterator_core_access::dereference(const Facade&) [with Facade = boost::iterators::zip_iterator<boost::tuples::tuple<unsigned int*, boost::array<double, 2u>*, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> >; typename Facade::reference = boost::tuples::cons<unsigned int&, boost::tuples::cons<boost::array<double, 2u>&, boost::tuples::null_type> >]' /usr/local/include/boost/iterator/iterator_facade.hpp:655:69: [ skipping 2 instantiation contexts, use -ftemplate-backtrace-limit=0 to disable ] /usr/local/lib/gcc49/include/c++/bits/stl_algobase.h:398:70: required from '_OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove = false; _II = boost::iterators::zip_iterator<boost::tuples::tuple<unsigned int*, boost::array<double, 2u>*, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> >; _OI = boost::iterators::zip_iterator<boost::tuples::tuple<unsigned int*, boost::array<double, 2u>*, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> >]' /usr/local/lib/gcc49/include/c++/bits/stl_algobase.h:436:38: required from '_OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove = false; _II = boost::iterators::zip_iterator<boost::tuples::tuple<unsigned int*, boost::array<double, 2u>*, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> >; _OI = boost::iterators::zip_iterator<boost::tuples::tuple<unsigned int*, boost::array<double, 2u>*, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> >]' /usr/local/lib/gcc49/include/c++/bits/stl_algobase.h:468:17: required from '_OI std::copy(_II, _II, _OI) [with _II = boost::iterators::zip_iterator<boost::tuples::tuple<unsigned int*, boost::array<double, 2u>*, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> >; _OI = boost::iterators::zip_iterator<boost::tuples::tuple<unsigned int*, boost::array<double, 2u>*, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> >]' asobj/flash/display/BitmapData_as.cpp:412:73: required from 'void gnash::{anonymous}::PerlinNoise<T, Size, Offset>::init(int) [with T = double; unsigned int Size = 256u; unsigned int Offset = 1327u]' asobj/flash/display/BitmapData_as.cpp:310:18: required from 'gnash::{anonymous}::PerlinNoise<T, Size, Offset>::PerlinNoise(int) [with T = double; unsigned int Size = 256u; unsigned int Offset = 1327u]' asobj/flash/display/BitmapData_as.cpp:1371:23: required from here /usr/local/include/boost/fusion/adapted/boost_tuple/detail/build_cons.hpp:53:59: error: no match for 'operator*' (operand type is 'const boost::fusion::transform_view_iterator<boost::fusion::boost_tuple_iterator<const boost::tuples::tuple<unsigned int*, boost::array<double, 2u>*, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> >, boost::iterators::detail::dereference_iterator>') typename result_of::value_of<First>::type v = *f; ^ /usr/local/include/boost/fusion/adapted/boost_tuple/detail/build_cons.hpp:53:59: note: candidate is: In file included from /usr/local/include/boost/fusion/adapted/boost_tuple/detail/build_cons.hpp:14:0, from /usr/local/include/boost/fusion/adapted/boost_tuple/detail/convert_impl.hpp:11, from /usr/local/include/boost/fusion/adapted/boost_tuple.hpp:20, from /usr/local/include/boost/iterator/zip_iterator.hpp:21, from asobj/flash/display/BitmapData_as.cpp:28: /usr/local/include/boost/fusion/iterator/deref.hpp:69:5: note: template<class Iterator> typename boost::fusion::result_of::deref<Iterator>::type boost::fusion::operator*(const boost::fusion::iterator_base<Derived>&) operator*(iterator_base<Iterator> const& i) ^ /usr/local/include/boost/fusion/iterator/deref.hpp:69:5: note: substitution of deduced template arguments resulted in errors seen above PR: 199601 Reported by: antoine (via exp-run) Changes: head/graphics/gnash/Makefile
Regain tracking for accepted regressions (bug 203179 folly).