Bug 532426 – 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.

• Status: RESOLVED OBSOLETE
• Product: Gentoo Linux

[Description Duncan 2014-12-13 10:43:21 UTC]

Created attachment 391544 [details]
emerge --info libraw

From the log:

>> Install libraw-0.16.0-r1 into /tmp/portage/media-libs/libraw-0.16.0-r1/image/ category media-libs
 * abi_x86_64.amd64: running multilib-minimal_abi_src_install
>>> Working in BUILD_DIR: "/tmp/portage/media-libs/libraw-0.16.0-r1/work/LibRaw-0.16.0-abi_x86_64.amd64"
make -j10 -l8 install.
[ 66%] [100%] Built target raw_r
Built target raw
Install the project...
-- Install configuration: "Gentoo"
-- Installing: /tmp/portage/media-libs/libraw-0.16.0-r1/image/usr/lib64/pkgconfig/libraw.pc
[snip]
-- Installing: /tmp/portage/media-libs/libraw-0.16.0-r1/image/usr/lib64/libraw_r.so.10
-- Installing: /tmp/portage/media-libs/libraw-0.16.0-r1/image/usr/lib64/libraw_r.so
CMake Error at cmake_install.cmake:129 (file):
  file called with network path DESTINATION.  This does not make sense when
  using DESTDIR.  Specify local absolute path or remove DESTDIR environment
  variable.
  
  DESTINATION=
  
  //share/cmake/Modules
  
  
Makefile:66: recipe for target 'install' failed
make: *** [install] Error 1
 * ERROR: media-libs/libraw-0.16.0-r1::gentoo failed (install phase):
 *   emake failed

[end log quote]

gentoo/~amd64, dev-util/cmake-3.0.2 installed, notably with USE=qt5 (-qt4), possibly explaining why nobody else seems to have filed the bug yet, tho it has been affecting me since libraw-0.16.0-r1 became available.  But I tried remerging libraw-0.16.0, which is already merged, and it fails with the same error, now.  But (r0) merged fine back on Jul 27, probably before I had qt5 merged, and cmake-3.0.2 was last remerged on Sep 25, which was probably when I switched it to USE=qt5. (I've been intermittently testing kde5/frameworks, tho kwin5 was still crashing on me last I tried, and of course various bits of kde4 and kde5 block each other so I have to keep returning to kde4.)

I just merged qt-5.4.0 I think yesterday, before which I had 5.3.2 (with the various -rX, qtcore 5.3.2 r1) merged, so that bump doesn't seem to have affected it.  I have the kde, x11 and qt overlays active but AFAIK not much actually installed from them ATM.  (Qt 4.6 and 5 and kde4-live, and of course the kde5/frameworks stuff when I try it, were installed from the overlays, but I'm back on in-tree versions ATM.)

Here's that section, lines 119-131, of the named (libraw) cmake_install.cmake file:

119 
120 if(NOT CMAKE_INSTALL_COMPONENT OR "${CMAKE_INSTALL_COMPONENT}" STREQUAL "Unspecified")
121   list(APPEND CMAKE_ABSOLUTE_DESTINATION_FILES
122    "//share/cmake/Modules/FindLibRaw.cmake")
123   if(CMAKE_WARN_ON_ABSOLUTE_INSTALL_DESTINATION)
124     message(WARNING "ABSOLUTE path INSTALL DESTINATION : ${CMAKE_ABSOLUTE_DESTINATION_FILES}")
125   endif()
126   if(CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION)
127     message(FATAL_ERROR "ABSOLUTE path INSTALL DESTINATION forbidden (by caller): ${CMAKE_ABSOLUTE_DESTINATION_FILES}")
128   endif()
129 file(INSTALL DESTINATION "//share/cmake/Modules" TYPE FILE FILES "/tmp/portage/media-libs/libraw-0.16.0-r1/work/LibRaw-0.16.0/cmake/modules/FindLibRaw.cmake
130 endif()
131 

But I don't understand why it's calling that a network path, unless it's simply due to the //.  I don't have any network filesystems configured.

One additional bit of system config that COULD be appropos, however:
I have usr/root unified via /usr being a symlink to ./, so /usr/share along with anything installed to it actually ends up as /share and installed there.


Full emerge --info libraw attached; the USE line from it:
media-libs/libraw-0.16.0 was built with the following:
USE="jpeg jpeg2k openmp -demosaic -examples -lcms"

... and from cmake:
dev-util/cmake-3.0.2 was built with the following:
USE="ncurses qt5 -doc -emacs -qt4 -test"

[Comment 1 Duncan 2014-12-13 10:53:00 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?

[Comment 2 Jeroen Roovers (RETIRED) 2014-12-13 11:00:59 UTC]

Please attach the entire build log to this bug report.

[Comment 3 Duncan 2014-12-13 11:15:35 UTC]

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. =:^)

[Comment 4 Duncan 2015-01-21 10:07:05 UTC]

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...

[Comment 5 Michael Palimaka (kensington) 2015-04-16 13:31:43 UTC]

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?

[Comment 6 Duncan 2015-05-16 10:24:06 UTC]

(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.

[Comment 7 Duncan 2015-07-18 16:48:27 UTC]

Another rebuild, another update, bumping affected libraw version range.  Problem still exists. =:^(

[Comment 8 Duncan 2015-10-09 12:08:59 UTC]

libraw-0.17.0 with cmake-3.3.2... finally builds and installs, apparently properly! =:^)

Updating status accordingly.