|
Description
Toralf Förster
2018-10-04 15:41:04 UTC
Created attachment 549290 [details]
emerge-info.txt
Created attachment 549292 [details]
CMakeError.log
Created attachment 549294 [details]
CMakeOutput.log
Created attachment 549296 [details]
emerge-history.txt
Created attachment 549298 [details]
environment
Created attachment 549300 [details]
etc.portage.tbz2
Created attachment 549302 [details]
logs.tbz2
Created attachment 549304 [details]
media-gfx:alembic-1.7.9:20181004-033126.log
Created attachment 549306 [details]
temp.tbz2
Hi Toralf, thanks for the report.
I can not reproduce the bug. There are standard cmake routines used to find boost>=1.42.0.
Could you please provide the ${BUILD_DIR}/CMakeCache.txt file?
appeared recently at the tinderbox image 17.0_20181006-205656 Created attachment 549646 [details]
emerge-info.txt
Created attachment 549648 [details]
CMakeError.log
Created attachment 549650 [details]
CMakeOutput.log
Created attachment 549652 [details]
emerge-history.txt
Created attachment 549654 [details]
environment
Created attachment 549656 [details]
etc.portage.tbz2
Created attachment 549658 [details]
logs.tbz2
Created attachment 549660 [details]
media-gfx:alembic-1.7.9:20181007-155837.log
Created attachment 549662 [details]
temp.tbz2
(In reply to Bernd from comment #10) FWIW it is in /var/tmp/portage/media-gfx/alembic-1.7.9/work/alembic-1.7.9_build/CMakeFiles/ or in /var/tmp/portage/media-gfx/alembic-1.7.9/work/alembic-1.7.9_build/ ? In /var/tmp/portage/media-gfx/alembic-1.7.9/work/alembic-1.7.9_build/CMakeCache.txt Toral, I still couldn't reproduce the error. I now used app-portage/ebuildtester to test the build in a stable amd64 docker container and it compiles fine. See the attached files, if you need some detail. The container has been using icu, python, nls and zlib USE flags for boost. Threads USE flag is enabled by default with boost, so it should reflect your installation of boost. I'm now going to do the same test against an unstable arch. Created attachment 550236 [details]
container contents of /etc/portage
Created attachment 550238 [details]
qlop -l output in container
Created attachment 550240 [details]
complete log of ebuildtester run
Finally could reproduce the bug with an unstable container. Because boost currently doesn't have an unstable version, I was thinking cmake could be root cause. And indeed, downgrading to stable 3.9.6 solve the configuration error. I then checked the cmake versions. Cmake-3.10.3 didn't compile due to libuv configuration error and starting with cmake-3.11.4-r1 the error pops up. So I guess, cmake has changed something in how it finds the boost library. I could save a CMakeCache.txt file, but looks like it doesn't have much information for this issue, at least less than I suspected. Now going to invetigate what has changed between cmake-3.9.6 and >=cmake-3.11*. Created attachment 550282 [details]
cmake cache file from cmake-3.12.3
Just noticed, on my machine, >=cmake-3.12.0 is masked due to an issue from science overlay. They have problems compiling lapack with those versions. I remember reading about it, but can't remember exactly what's their problem with it. Maybe it is tied to this one. I will check this. Found a bug #660980 for 3.11 describing the same problem. For the time, I found a workaround for the package. Could you please try, whether the attached ebuild and the two additional patches solve the problem for you? They work on my machine using cmake-3.12.3. Created attachment 550290 [details]
alembic-1.7.9.ebuild
includes experimental workaround for the bug.
Created attachment 550292 [details, diff]
patch to find boost_python for >=cmake-3.11
Created attachment 550294 [details, diff]
fixes new naming scheme for boost_python in cmake
Toralf, could you test the patches already? (In reply to Bernd from comment #34) Well, this is an issue catched by the tinderbox having >2K bugs open reports till now. I do usually do not test individual patches, except in very rare cases ... Ok, so how is it supposed to handle such tinderbox bugs, which get confirmed automatically, without being confirmed by at least a second person, if the reporter can not test fixes? (In reply to Bernd from comment #36) > Ok, so how is it supposed to handle such tinderbox bugs, which get confirmed > automatically, without being confirmed by at least a second person, if the > reporter can not test fixes? You reproduced the issue, so test the fix yourself. (In reply to Michał Górny from comment #37) > You reproduced the issue, so test the fix yourself. If you follow the thread, you might recognize, I already tested it, see comment #30. So be it. I just open a PR for it! Actually my mistake, not a stable package. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4564c5566b6c2450c8b627c997422c0e5a490ec3 commit 4564c5566b6c2450c8b627c997422c0e5a490ec3 Author: Bernd Waibel <waebbl@gmail.com> AuthorDate: 2018-11-11 20:55:57 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2019-05-08 16:59:31 +0000 media-gfx/alembic: fix boost not found error Fixes an error with >=cmake-3.11* where boost is not found due to changes in cmake syntax. See also: https://github.com/gentoo/gentoo/pull/10394 Closes: https://bugs.gentoo.org/667728 Package-Manager: Portage-2.3.51, Repoman-2.3.12 Signed-off-by: Bernd Waibel <waebbl@gmail.com> Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> media-gfx/alembic/alembic-1.7.9.ebuild | 9 ++++----- ...c-1.7.9-find-boost-python-for-cmake-ge-3.11.patch | 20 ++++++++++++++++++++ .../alembic-1.7.9-fix-boost-python-naming.patch | 17 +++++++++++++++++ 3 files changed, 41 insertions(+), 5 deletions(-) |
