Created attachment 192339 [details] Patch against ports r463565 kde@ would like to ask for an exp-run to upgrade cmake to 3.11.0. The patch is attached, and can also be found in Phab review D14506
New failures on 11.1 amd64: http://package22.nyi.freebsd.org/data/111amd64-default-PR227372/2018-04-13_12h26m36s/logs/errors/kwave-17.12.3.log http://package22.nyi.freebsd.org/data/111amd64-default-PR227372/2018-04-13_12h26m36s/logs/errors/kig-17.12.3.log http://package22.nyi.freebsd.org/data/111amd64-default-PR227372/2018-04-13_12h26m36s/logs/errors/ktorrent-5.1.0.log
New failures on 11.1 i386: http://package23.nyi.freebsd.org/data/111i386-default-PR227372/2018-04-13_11h19m57s/logs/errors/kwave-17.12.3.log http://package23.nyi.freebsd.org/data/111i386-default-PR227372/2018-04-13_11h19m57s/logs/errors/kig-17.12.3.log http://package23.nyi.freebsd.org/data/111i386-default-PR227372/2018-04-13_11h19m57s/logs/errors/ktorrent-5.1.0.log
New failures on 10.3 amd64: http://package22.nyi.freebsd.org/data/103amd64-default-PR227372/2018-04-13_19h38m50s/logs/errors/kwave-17.12.3.log http://package22.nyi.freebsd.org/data/103amd64-default-PR227372/2018-04-13_19h38m50s/logs/errors/kig-17.12.3.log http://package22.nyi.freebsd.org/data/103amd64-default-PR227372/2018-04-13_19h38m50s/logs/errors/ktorrent-5.1.0.log
New failures on 10.3 i386: http://package23.nyi.freebsd.org/data/103i386-default-PR227372/2018-04-13_19h38m53s/logs/errors/kwave-17.12.3.log http://package23.nyi.freebsd.org/data/103i386-default-PR227372/2018-04-13_19h38m53s/logs/errors/kig-17.12.3.log http://package23.nyi.freebsd.org/data/103i386-default-PR227372/2018-04-13_19h38m53s/logs/errors/ktorrent-5.1.0.log
A commit references this bug: Author: adridg Date: Sun Apr 15 21:43:58 UTC 2018 New revision: 467437 URL: https://svnweb.freebsd.org/changeset/ports/467437 Log: Update CMake to 3.11.0. Thanks to antoine@ for the exp-run. In the run-up to this commit, many other ports were pre-emptively fixed. The only issue still known is math/kig, which had a build failure in the exp-run, but which isn't reproducible across multiple 11.1 {i386,amd64} machines and poudriere builds. We've decided to forge ahead. The new CMake version: - drops FreeBSD patches that have been incorporated upstream, - re-shuffles patches to FindQt4, since upstream has made some changes which break FindQt4 in new ways on FreeBSD (while fixing the old ones), - has new patches to make OpenMP and BLAS findable on FreeBSD, - drops ports libarchive in favor of the version in base, to avoid overlinking for the pkg(8) support in CPack (this makes portlint complain, and we have decided to ignore it). PR: 227372 226959 223678 Approved by: tcberner (mentor) Differential Revision: https://reviews.freebsd.org/D14506 Changes: head/devel/cmake/Makefile head/devel/cmake/distinfo head/devel/cmake/files/InitialCache.cmake head/devel/cmake/files/patch-Modules_FindBLAS.cmake head/devel/cmake/files/patch-Modules_FindImageMagick.cmake head/devel/cmake/files/patch-Modules_FindOpenMP.cmake head/devel/cmake/files/patch-Modules_FindQt4.cmake head/devel/cmake/files/patch-Modules_FindwxWidgets.cmake head/devel/cmake/files/patch-Modules_FindwxWindows.cmake head/devel/cmake/files/patch-git_3f4924-boost_1.66 head/devel/cmake/pkg-plist head/devel/cmake-doc/Makefile head/devel/cmake-doc/pkg-plist head/devel/cmake-gui/Makefile
Created attachment 192542 [details] Build log of poudriere (In reply to commit-hook from comment #5) After this commit build fails in stage-qa phase. Attached file is build log of poudriere. Build conditions: Host: 11.1-RELEASE-p9 amd64 Jail: 11.1-RELEASE-p9 amd64 Ports tree: ports r467439
(In reply to Yasuhiro KIMURA from comment #6) Yes, that is exactly the overlinking problem we have chosen to ignore. We do not want to explicitly make CMake depend on pkg, because pkg and pkg-devel conflict with each other. We do not want to add USES=libarchive, because pkg links to base libarchive (.so.6) while ports provides .so.13 (or later).
(In reply to Adriaan de Groot from comment #7) OK, I understand what you think is problem. But as a simple fact, currently this port cannot be build with poudriere. And as far as I tried same error happens on real 11.1-RELEASE environment. So would you mind my asking under what conditions this port currently can be build successfully?
(In reply to Yasuhiro KIMURA from comment #8) 'stage-qa' fails here for me as well on 10/stable... Error: Bad linking on libarchive.so.6 for please add USES=libarchive Error: /usr/local/bin/ccmake is linked to /usr/local/lib/libarchive.so.13 from archivers/libarchive but it is not declared as a dependency Warning: you need USES+=libarchive Error: /usr/local/bin/cpack is linked to /usr/local/lib/libpkg.so.4 from ports-mgmt/pkg but it is not declared as a dependency Warning: you need LIB_DEPENDS+=libpkg.so:ports-mgmt/pkg
Perhaps Mk/Uses/libarchive.mk could grow support for base libarchive (similar to Uses/iconv.mk).
I will add that if the libarchive port is installed, cmake will like with that version (/usr/local/lib/libarchive.so.13). But the libarchive dependency is now not flagged as a dependency. Then if the user later removes the libarchive package, cmake will break: Shared object "libarchive.so.13" not found, required by "ccmake" If you want to disable linking with the port version of libarchive, you need to be more explicit (either in devel/cmake and/or adding the option in Mk/Uses/libarchive.mk). The 'pkg' dependency will have a similar problem.
(In reply to John Hein from comment #11) I'm surprised an exp-run doesn't catch these Q/A problems. Or are they ignored?
With all these considerations -- we will be updating the CMake port shortly (tuesday or wednesday) to make pkg optional *or* to make stage-qa accept the port. It depends on what is technically feasible; goal is that a poudriere build with -t (which runs stage-qa) will actually succeed.
exp-runs never run with bulk -t as there are so many ports that will fail with it.
(In reply to Mathieu Arnold from comment #14) Understood re: no bulk -t for exp-runs. Thanks.
(In reply to Adriaan de Groot from comment #13) Maybe there's a way to really force cmake/ccmake/etc. to link with /usr/lib/libarchive.so. Clearly, the InitialCache.cmake addition to try to force /usr/lib/libarchive.so is not working somehow. After 'configure' there are a few link.txt files that have '-larchive' instead of /usr/lib/libarchive.so. I haven't tracked down why yet. If we solve that, then we don't need to disable any Q/A tests (which seem to be helpful and doing the right thing). Nor should we have to make pkg optional. Anyone have an idea where the -larchive comes from (despite specifying LibArchive_LIBRARY=/usr/lib/libarchive.so)?
A commit references this bug: Author: adridg Date: Tue Apr 17 18:00:40 UTC 2018 New revision: 467620 URL: https://svnweb.freebsd.org/changeset/ports/467620 Log: Fix stage-qa problems with devel/cmake Linking to base libarchive is disallowed by stage-qa, so restore USES=libarchive (to avoid the bundled libarchive and to link to ports libarchive) and drop the pkg(8) generator for CPack, since libpkg in turn pulls in base libarchive. PR: 227372 Approved by: tcberner (mentor, implicit) Changes: head/devel/cmake/Makefile head/devel/cmake/files/InitialCache.cmake
(In reply to Yasuhiro KIMURA from comment #6) Thank you for your earlier comments. Could you please confirm that CMake 3.11.0_1 (latest ports) does build in your poudriere setup?
(In reply to Adriaan de Groot from comment #18) I checked with ports r467657 and confirmed this port can be build successfuly on both poudriere and real environment. Thank you for fixing the problem.
Can we close this one?
(In reply to Raphael Kubo da Costa from comment #20) Yes, I agree to close this bug report.
Yes. There is a new one for 3.11.1 here: #227824, which should also address #227573.