Summary: | media-libs/libraw-0.16.0-r1- media-libs/libraw-0.16.2 with dev-util/cmake-3.0.2 thru 3.2.2 - src_install(): CMake Error at cmake_install.cmake:129 (file): file called with network path DESTINATION. This does not make sense when using DESTDIR. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Duncan <1i5t5.duncan> |
Component: | [OLD] Library | Assignee: | Gentoo Graphics Project <graphics+disabled> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | kensington |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge --info libraw
Full build-log |
Description
Duncan
2014-12-13 10:43:21 UTC
OK, tried rebuilding cmake with USE="-qt5 qt4", and then tried building libraw again, and same error. So it doesn't seem to be cmake USE=qt5 related. Would the /usr symlinked to / cause the //share path and thus the bug? Please attach the entire build log to this bug report. Created attachment 391556 [details]
Full build-log
Full (failure) build log.
Tried reverting to cmake-2.8.12.2-r2...
and libraw-0.16.0-r1 MERGED! =:^)
Upgraded to cmake-3.0.2 again and tried libraw again, and it FAILED.
So the problem would definitely seem to be cmake-3 related. Presumably with the logged DESTDIR/DESTINATION complaint and that additional info, the problem should be reasonably easy to fix. =:^)
Ugh. Just ran into this again with an --emptytree @world rebuild after upgrading to gcc-4.9.2 (from 4.8.x). Still unfixed, and had to lookup the bug to see what workaround I had used last time. =:^( Nobody cced tho, so I guess nobody else rebuilding libraw is running cmake-3.x, or if they are they aren't triggering the bug for whatever reason... Indeed, when checking destination, cmake interprets any value beginning with "//" as a network path (grep for the error in Source/cmFileCommand.cxx from cmake source). Could you please paste the result of grep CMAKE_ROOT CMakeCache.txt from the build dir? (In reply to Michael Palimaka (kensington) from comment #5) > [P]lease paste the result of grep CMAKE_ROOT CMakeCache.txt from the > build dir? Hmm... forgot about this bug until the blocker changes, but just tried again with cmake-3.2.2 and still seeing the problem. Here's the requested grep results from that run: CMAKE_ROOT:INTERNAL=//share/cmake I suspect I know why nobody else is seeing this now! =:^) I have the /usr merge done here, to /, however, not to /usr, as I prefer the shorter paths. So /usr is a symlink: /usr -> . ... which places the traditional /usr/share at /share. So I don't know where the //share/cmake path ultimately sources from, but you nailed the CMAKE_ROOT bit, and it's almost certainly due to something misprocessing my /usr -> . symlink, deleting just the usr instead of /usr, thus leaving that //share. Another rebuild, another update, bumping affected libraw version range. Problem still exists. =:^( libraw-0.17.0 with cmake-3.3.2... finally builds and installs, apparently properly! =:^) Updating status accordingly. |